home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
InfoMagic Standards 1994 January
/
InfoMagic Standards - January 1994.iso
/
ccitt
/
1988
/
troff
/
8_7_04.tro
< prev
next >
Wrap
Text File
|
1991-12-22
|
113KB
|
4,976 lines
.rs
.\" Troff code generated by TPS Convert from ITU Original Files
.\" Not Copyright (~c) 1991
.\"
.\" Assumes tbl, eqn, MS macros, and lots of luck.
.TA 1c 2c 3c 4c 5c 6c 7c 8c
.ds CH
.ds CF
.EQ
delim @@
.EN
.nr LL 40.5P
.nr ll 40.5P
.nr HM 3P
.nr FM 6P
.nr PO 4P
.nr PD 9p
.po 4P
.rs
\v'|.5i'
.LP
\fBMONTAGE: FIN DE LA SECTION 2 EN\(hyT\*\|ETE DE CETTE PAGE\fR
.LP
\v'20P'
SECTION\ 3\ \(em\ CONFIGURATIONS
.sp 1P
.RT
.sp 2P
.LP
\fB11\fR \fBOverview\fR
.EF '% Fascicle\ VIII.7\ \(em\ Rec.\ X.402''
.OF '''Fascicle\ VIII.7\ \(em\ Rec.\ X.402 %'
.sp 1P
.RT
.PP
This section specifies how one can configure the MHS to satisfy any of
a variety of functional, physical, and organizational requirements.
.PP
This section covers the following topics:
.RT
.LP
a)
functional configurations;
.LP
b)
physical configurations;
.LP
c)
organizational configurations;
.LP
d)
the \fIGlobal MHS\fR .
.sp 2P
.LP
\fB12\fR \fBFunctional configurations\fR
.sp 1P
.RT
.PP
This clause specifies the possible functional configurations of the MHS.
The variety of such configurations results from the presence or absence
of the Directory, and from whether a direct user employs an MS.
.RT
.sp 1P
.LP
12.1
\fIRegarding the Directory\fR
.sp 9p
.RT
.PP
With respect to the Directory, the MHS can be configured for a
particular user, or a collection of users (e.g.,\ see \(sc\ 14.1), in either
of two ways: with or without the Directory. A user without access to the
Directory may lack the capabilities described in Section\ 5.
.PP
\fINote\fR \ \(em\ A partially, rather than fully, interconnected directory
may exist for an interim period during which the (global) Directory made
possible by Recommendations for Directories is under construction.
.RT
.sp 1P
.LP
12.2
\fIRegarding the message store\fR
.sp 9p
.RT
.PP
With respect to the MS, the MHS can be configured for a particular direct
user in either of two ways: with or without an MS. A user without access
to an MS lacks the capabilities of message storage. A user in such
circumstances depends upon his UA for the storage of information objects, a
capability that is a local matter.
.PP
The two functional configurations identified above are depicted in
Figure\ 7/X.402 which also illustrates one possible configuration of the MTS,
and its linkage to another communication system via an AU. In the figure,
user\ 2 is equipped with an MS while user\ 1 is not.
.bp
.RT
.LP
.rs
.sp 22P
.ad r
\fBFigure 7/X.402, p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 2P
.LP
\fB13\fR \fBPhysical configurations\fR
.sp 1P
.RT
.PP
This clause specifies the possible physical configurations of the MHS,
i.e.,\ how the MHS can be realized as a set of interconnected computer
systems. Because the number of configurations is unbounded, the clause
describes the kinds of messaging systems from which the MHS is assembled,
and identifies a few important representative configurations.
.RT
.sp 1P
.LP
13.1
\fIMessaging systems\fR
.sp 9p
.RT
.PP
The building blocks used in the physical construction of the MHS
are called \fImessaging systems\fR . A \fBmessaging system\fR is a computer
system
(possibly but not necessarily an open system) that contains, or realizes,
one or more functional objects.
.PP
Messaging systems are of the types depicted in Figure 8/X.402.
.RT
.PP
The types of messaging system, depicted in Figure 8/X.402, are
listed in the first column of Table\ 8/X.402. For each type listed, the
second column indicates the kinds of functional object \(em\ UAs, MSs,
MTAs, and AUs\ \(em
that
may be present in such a messaging system, whether their presence is mandatory
or optional, and whether just one or possibly several of them may be present
in the messaging system. The table is divided into two sections. Messaging
systems of the types in the first section are dedicated to single users,
those of the types in the second can (but need not) serve multiple users.
.PP
Table 8/X.402 is divided into two sections. Messaging systems of the types
in the first section are dedicated to single users, those of the types
in the second can (but need not) serve multiple users.
.RT
.PP
\fINote\fR \ \(em\ The following major principles governed the admission
of messaging system types:
.LP
a)
An AU and the MTA with which it interacts are typically
co\(hylocated because no protocol to govern their interaction is standardized.
.LP
b)
An MTA is typically co\(hylocated with multiple UAs or MSs
because, of the standardized protocols, only that for transfer simultaneously
conveys a message to multiple recipients. The serial delivery of a message
to multiple recipients served by a messaging system, which the delivery
protocol would require, would be inefficient.
.bp
.LP
c)
No purpose is served by co\(hylocating several MTAs in a
messaging system because a single MTA serves multiple users, and the purpose
of an MTA is to convey objects between, not within such systems. (This
is not
intended to exclude the possibility of several MTA\(hyrelated processes
co\(hyexisting within a single computer system.)
.LP
d)
The co\(hylocation of an AU with an MTA does not affect that
system's behaviour with respect to the rest of the MHS. A single messaging
system type, therefore, encompasses the AU's presence and absence.
.PP
The messaging system types, summarized in Table 8/X.402, are
individually defined and described below.
.LP
.rs
.sp 21P
.ad r
\fBFigure 8/X.402, p.2\fR
.sp 1P
.RT
.ad b
.RT
.ce
\fBH.T. [T8.402]\fR
.ce
TABLE\ 8/X.402
.ce
\fBMessaging systems\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(72p) | cw(24p) sw(24p) sw(24p) sw(24p) , ^ | c | c | c | c.
Messaging system Functional objects
UA MS MTA AU
_
.T&
lw(72p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) .
A/SYS 1 \(em \(em \(em
.T&
lw(72p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) .
S/SYS \(em 1 \(em \(em
.T&
lw(72p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) .
AS/SYS 1 1 \(em \(em
_
.T&
lw(72p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) .
T/SYS \(em \(em 1 [M]
.T&
lw(72p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) .
AT/SYS M \(em 1 [M]
.T&
lw(72p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) .
ST/SYS \(em M 1 [M]
.T&
lw(72p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) .
AST/SYS M M 1 [M]
_
.T&
lw(72p) | lw(24p) | cw(24p) | cw(24p) | cw(24p) .
M Multiple .parag [.\|.\|.] Optional .parag
.TE
.nr PS 9
.RT
.ad r
\fBTableau 8/X.402 [T8.402], p.3\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 1P
.LP
13.1.1
\fIAccess systems\fR
.sp 9p
.RT
.PP
An \fBaccess system (A/SYS)\fR contains
one UA and neither an MS, an
MTA, nor an AU.
.PP
An A/SYS is dedicated to a single user.
.RT
.sp 1P
.LP
13.1.2
\fIStorage systems\fR
.sp 9p
.RT
.PP
A \fBstorage system (S/SYS)\fR contains one MS and neither a UA, an MTA,
nor an AU.
.PP
An S/SYS is dedicated to a single user.
.RT
.sp 1P
.LP
13.1.3
\fIAccess and storage systems\fR
.sp 9p
.RT
.PP
An \fBaccess and storage system (AS/SYS)\fR contains one UA, one MS, and
neither an MTA nor an AU.
.PP
An AS/SYS is dedicated to a single user.
.RT
.sp 1P
.LP
13.1.4
\fITransfer systems\fR
.sp 9p
.RT
.PP
A \fBtransfer system (T/SYS)\fR contains one MTA; optionally, one or more
AUs; and neither a UA nor an\ MS.
.PP
A T/SYS can serve multiple users.
.RT
.sp 1P
.LP
13.1.5
\fIAccess and transfer systems\fR
.sp 9p
.RT
.PP
An \fBaccess and transfer system (AT/SYS)\fR contains one or more
UAs; one MTA; optionally, one or more AUs; and no MS.
.PP
An AT/SYS can serve multiple users.
.RT
.sp 1P
.LP
13.1.6
\fIStorage and transfer systems\fR
.sp 9p
.RT
.PP
A \fBstorage and transfer system (STB/FSYS)\fR contains one or more MSs;
one MTA; optionally, one or more AUs; and no UA.
.PP
An ST/SYS can serve multiple users.
.RT
.sp 1P
.LP
13.1.7
\fIAccess, storage, and transfer systems\fR
.sp 9p
.RT
.PP
An \fBaccess, storage, and transfer system (AST/SYS)\fR contains
one or more UAs; one or more MSs; one MTA; and optionally, one or more AUs.
.PP
An AST/SYS can serve multiple users.
.RT
.sp 1P
.LP
13.2
\fIRepresentative configurations\fR
.sp 9p
.RT
.PP
Messaging systems can be combined in various ways to form the MHS. The
possible physical configurations are unbounded in number and thus cannot
be enumerated. Several important representative configurations, however,
are
described below and in Figure\ 9/X.402.
.RT
.sp 1P
.LP
13.2.1
\fIFully centralized\fR
.sp 9p
.RT
.PP
The MHS may be fully centralized [panel a) of Figure 9/X.402]. This design
is realized by a single AST/SYS which contains functional objects of all
kinds and which can serve multiple users.
.RT
.sp 1P
.LP
13.2.2
\fICentralized message transfer and storage\fR
.sp 9p
.RT
.PP
The MHS may provide both message transfer and message storage
centrally but user access distributedly [panel\ b) of Figure\ 9/X.402]. This
design is realized by a single ST/SYS and, for each user, an A/SYS.
.RT
.sp 1P
.LP
13.2.3
\fICentralized message transfer\fR
.sp 9p
.RT
.PP
The MHS may provide message transfer centrally but message storage and
user access distributedly [panel\ c) of Figure\ 9/X.402]. This design is
realized by a single T/SYS and, for each user, either an AS/SYS alone or an
S/SYS and an associated A/SYS.
.bp
.RT
.LP
.rs
.sp 29P
.ad r
\fBFigure 9/X.402, p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
13.2.4
\fIFully distributed\fR
.sp 9p
.RT
.PP
The MHS may provide even message transfer distributedly [panel d) of Figure\
9/X.402]. This design involves multiple ST\(hySYSs or T\(hySYSs.
.RT
.sp 2P
.LP
\fB14\fR \fBOrganizational configurations\fR
.sp 1P
.RT
.PP
This clause specifies the possible organizational configurations of the
MHS, i.e.,\ how the MHS can be realized as interconnected but independently
managed sets of messaging systems (which are themselves interconnected).
Because the number of configurations is unbounded, the clause describes the
kinds of \fImanagement domains\fR from which the MHS is assembled, and
identifies a few important representative configurations.
.RT
.sp 1P
.LP
14.1
\fIManagement domains\fR
.sp 9p
.RT
.PP
The primary building blocks used in the organizational construction of
the MHS are called \fImanagement domains\fR . A \fBmanagement domain\fR
(MD) (or
\fBdomain\fR ) is a set of messaging systems \(em\ at least one of which
contains, or
realizes, an MTA\ \(em that is managed by a single organization.
.PP
The above does not preclude an organization from managing a set of
messaging systems (e.g.,\ a single A/SYS) that does not qualify as an MD for
lack of an MTA. Such a collection of messaging systems, a secondary building
block used in the MHS' construction, \*Qattaches\*U to an MD.
.PP
MDs are of several types which are individually defined and described below.
.bp
.RT
.sp 1P
.LP
14.1.1
\fIAdministration management domains\fR
.sp 9p
.RT
.PP
An \fBadministration management domain (ADMD)\fR comprises messaging systems
managed by an Administration. The major technical distinction between an
ADMD and a \fIPRMD\fR is that the former is positioned above the latter
in the MHS' hierarchical addressing (see \(sc\ 18) and routing (see \(sc\
19) regimes.
.PP
\fINote\fR \ \(em\ An ADMD provides Message Handling to the public.
.RT
.sp 1P
.LP
14.1.2
\fIPrivate management domains\fR
.sp 9p
.RT
.PP
A \fBprivate management domain (PRMD)\fR comprises messaging systems managed
by an organization other than an Administration. The major technical
distinction between a PRMD and an ADMD is that the former is positioned
below the latter in the MHS' hierarchical addressing (see \(sc\ 18) and
routing (see
\(sc\ 19) regimes.
.PP
\fINote\fR \ \(em\ A PRMD provides message handling, e.g., to the employees
of a company, or to those employees at a particular company site.
.RT
.sp 1P
.LP
14.2
\fIRepresentative configurations\fR
.sp 9p
.RT
.PP
MDs can be combined in various ways to form the MHS. The possible organizational
configurations are unbounded in number and thus cannot be
enumerated. Several important representative configurations, however, are
described below and in Figure\ 10/X.402.
.RT
.LP
.rs
.sp 18P
.ad r
\fBFigure 10/X.402, p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
14.2.1
\fIFully centralized\fR
.sp 9p
.RT
.PP
The entire MHS may be managed by one organization [panel a) of
Figure\ 10/X.402]. This design is realized by a single MD.
.RT
.sp 1P
.LP
14.2.2
\fIDirectly connected\fR
.sp 9p
.RT
.PP
The MHS may be managed by several organizations, the messaging
systems of each connected to the messaging systems of all of the others
[panel\ b) of Figure\ 10/X.402]. This design is realized by multiple MDs
interconnected pair\(hywise.
.RT
.sp 1P
.LP
14.2.3
\fIIndirectly connected\fR
.sp 9p
.RT
.PP
The MHS may be managed by several organizations, the messaging
systems of one serving as intermediary between the messaging systems of the
others [panel\ c) of Figure\ 10/X.402]. This design is realized by multiple
MDs one of which is interconnected to all of the others.
.bp
.RT
.sp 2P
.LP
\fB15\fR \fBThe \fR \fBGlobal MHS\fR
.sp 1P
.RT
.PP
A major purpose of this Recommendation and others in the set is to enable
the construction of the Global MHS, an MHS providing both intra\(hy and
inter\(hyorganizational, and both intra\(hy and international message handling
world\(hywide.
.PP
The Global MHS almost certainly encompasses the full variety of
functional configurations specified in\ \(sc\ 12.
.PP
The physical configuration of the Global MHS is a hybrid of the pure configurations
specified in \(sc\ 13, extremely complex and highly distributed
physically.
.PP
The organizational configuration of the Global MHS is a hybrid of the pure
configurations specified in\ \(sc\ 14, extremely complex and highly distributed
organizationally.
.PP
Figure 11/X.402 gives an example of possible interconnections. It does
not attempt to identify all possible configurations. As depicted, ADMDs
play a central role in the Global MHS. By interconnecting to one another
internationally, they provide an international message transfer backbone.
Depending upon national regulations, by interconnecting to one another
domestically, they may also provide domestic backbones joined to the
international backbone. ADMDs also serve as primary naming authorities
in the assignment of \fIO/R addresses\fR to users and\ DLs.
.PP
PRMDs play a peripheral role in the Global MHS, being connected to the
ADMD backbone which serves as an intermediary between them.
.RT
.LP
.rs
.sp 14P
.ad r
\fBFigure 11/X.402, p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
SECTION\ 4\ \(em\ NAMING, ADDRESSING, AND\ ROUTING
.sp 1P
.RT
.sp 2P
.LP
\fB16\fR \fBOverview\fR
.sp 1P
.RT
.PP
This section describes the naming and addressing of users and DLs and the
routing of information objects to them.
.PP
This section covers the following topics:
.RT
.LP
a)
Naming;
.LP
b)
Addressing;
.LP
c)
Routing
.sp 2P
.LP
\fB17\fR \fBNaming\fR
.sp 1P
.RT
.PP
This paragraph specifies how users and DLs are named for the
purposes
of message handling in general and message transfer in particular. It defines
\fIO/R names\fR and describes the role that Directory names play in them.
.PP
When it directly submits a message or probe, a UA or MS identifies its
potential recipients to the MTS. When the MTS delivers a message, it identifies
the originator to each recipient's UA or MS. \fIO/R names\fR are the data
structures by means of which such identification is achieved.
.bp
.RT
.sp 1P
.LP
17.1
\fIDirectory names\fR
.sp 9p
.RT
.PP
A Directory name is one component of an \fIO/R name\fR . A Directory
name identifies an object to the Directory. By presenting such a name to the
Directory, the MHS can access a user's or DL's Directory entry. From that
entry the MTS can obtain, e.g.,\ the user's or DL's \fIO/R address\fR .
.PP
Not every user or DL is registered in the Directory and, therefore,
not every user or DL possesses a Directory name.
.PP
\fINote\ 1\fR \ \(em\ Many users and DLs will lack Directory names until the
Directory is widely available as an adjunct to the MHS. Many indirect users
(e.g.,\ postal patrons) will lack such names until the Directory is widely
available as an adjunct to other communication systems.
.PP
\fINote\ 2\fR \ \(em\ Users and DLs may be assigned Directory names even
before a fully interconnected, distributed Directory has been put in place
by
pre\(hyestablishing the naming authorities upon which the Directory will
eventually depend.
.PP
\fINote\ 3\fR \ \(em\ The typical Directory name is more user\(hyfriendly
and more stable than the typical \fIO/R address\fR because the latter is
necessarily couched in terms of the organizational or physical structure
of the MHS while the
former need not be. Therefore, it is intended that over time, Directory
names become the primary means by which users and DLs are identified outside
the MTS (i.e.\ by other users), and that the use of \fIO/R address\fR be
largely confined to the MTS (i.e.,\ to use by MTAs).
.RT
.sp 1P
.LP
17.2
\fIO/R names\fR
.sp 9p
.RT
.PP
Every user or DL has one or more \fIO/R names\fR . An \fBO/R name\fR is
an identifier by means of which a user can be designated as the originator,
or a user or DL designated as a potential recipient of a message or probe.
An O/R
name distinguishes one user or DL from another and may also identify its
point of access to the MHS.
.PP
An O/R name comprises a Directory name, an \fIO/R address\fR , or both.
If present, the Directory name (if valid) unambiguously identifies the
user or DL (but is not necessarily the only name that would do so). If
present, the
\fIO/R address\fR does the same and more (again see \(sc\ 18.5).
.PP
At direct submission, the UA or MS of the originator of a message or probe
may include either or both components in each OB/FR name it supplies. If
the \fIO/R address\fR is omitted, the MTS obtains it from the Directory
using the Directory name. If the Directory name is omitted, the MTS does
without it. If both are included, the MTS relies firstly upon the \fIO/R
address\fR . Should it
determine that the \fIO/R address\fR is invalid (e.g.,\ obsolete), it proceeds
as if the \fIO/R address\fR had been omitted, relying upon the Directory
name.
.PP
At delivery the MTS includes an \fIO/R address\fR and possibly a Directory
name in each O/R name it supplies to a message's recipient or to the originator
of a report's subject message or probe. The Directory name is included
if the originator supplied it or if it was specified as the the member
of an expanded DL.
.PP
\fINote\fR \ \(em\ Redirection or DL expansion may cause the MTS to convey
to a UA or MS at delivery, O/R names the UA or MS did not supply at direct
submission.
.RT
.sp 2P
.LP
\fB18\fR \fBAddressing\fR
.sp 1P
.RT
.PP
This paragraph specifies how users and DLs are addressed. It
defines \fIO/R addresses\fR , describes the structure of the \fIattribute
lists\fR from which they are constructed, discusses the character sets
from which individual \fIattributes\fR are composed, gives rules for determining
that two \fIattribute
lists\fR are equivalent and for the inclusion of conditional \fIattributes\fR
in such lists, and defines the \fIstandard attributes\fR that may appear
in them.
.PP
To convey a message, probe, or report to a user, or to expand a DL
specified as a potential recipient of a message or probe, the MTS must
locate the user or DL relative to its own physical and organizational structures.
\fIO/R addresses\fR are the data structures by means of which all such
location is
accomplished.
.bp
.RT
.sp 1P
.LP
18.1
\fIAttribute lists\fR
.sp 9p
.RT
.PP
The \fIO/R addresses\fR of both users and DLs are attribute lists. An \fBattribute
list\fR is an ordered set of \fIattributes\fR .
.PP
An \fBattribute\fR is an information item that describes a user or DL and
that may also locate it in relation to the physical or organizational
structure of the MHS (or the network underlying it).
.PP
An attribute has the following parts:
.RT
.LP
a)
\fBattribute type\fR (\fBor type\fR ): An identifier that denotes a class
of information (e.g.,\ personal names).
.LP
b)
\fBattribute value\fR (\fBor value\fR ): An instance of the class of
information the attribute type denotes (e.g.,\ a particular personal
name).
.PP
Attributes are of the following two kinds:
.LP
a)
\fBstandard attribute\fR : An attribute
whose type is bound to a class of
information by this Recommendation.
.LP
The value of every standard attribute except terminal\(hytype is either
a string or a collection of strings.
.LP
b)
\fBdomain\(hydefined attribute\fR : An attribute whose type is
bound to a class of information by an MD.
.LP
Both the type and value of every domain\(hydefined attribute
are strings or collections of strings.
.PP
\fINote\fR \ \(em\ The widespread use of standard attributes produces more
uniform and thus more user\(hyfriendly OB/FR addresses. However, it is
anticipated that not all MDs will be able to employ such attributes immediately.
The
purpose of domain\(hydefined attributes is to permit an MD to retain its
existing, native addressing conventions for a time. It is intended, however,
that all MDs migrate toward the use of standard attributes, and that domain\(hydefined
attributes be used only for an interim period.
.sp 1P
.LP
18.2
\fICharacter sets\fR
.sp 9p
.RT
.PP
Standard attribute values and domain\(hydefined
attribute types and values are
constructed from numeric, printable, and teletex
strings as follows:
.RT
.LP
a)
The type or value of a particular domain\(hydefined attribute may be
a printable string, a teletex string, or both. The same choice shall be
made for both the type and value.
.LP
b)
The kinds of strings from which standard attribute values
may be constructed and the manner of construction (e.g.,\ as one string or
several) vary from one attribute to another (see \(sc\ 18.3).
.PP
The value of an attribute comprises strings of one of the
following sets of varieties depending upon its type: numeric only, printable
only, numeric and printable, and printable and teletex. With respect to
this, the following rules govern each instance of communication:
.LP
a)
Wherever both numeric and printable strings are permitted, strings of
either variety (but not both) may be supplied equivalently.
.LP
b)
Wherever both printable and teletex strings are permitted, strings of
either or both varieties may be supplied, but printable strings
shall be supplied as a minimum whenever attributes are conveyed
internationally. If both printable and teletex strings are supplied, the two
should convey the same information so that eiher of them can be safely
ignored upon receipt.
.PP
The length of each string and of each sequence of strings in an
attribute shall be limited as indicated in the more detailed (i.e.,\ ASN.1)
specification of attributes in Recommendation X.411.
.PP
\fINote\ 1\fR \ \(em\ Teletex strings are permitted in attribute values
to allow inclusion, e.g.,\ of the accented characters commonly used in
many countries.
.PP
\fINote\ 2\fR \ \(em\ Not all inputB/Foutput devices permit the entry and
display, e.g.,\ of accented characters. printable strings are required
internationally to ensure that such device limitations do not prevent communication.
.bp
.RT
.sp 1P
.LP
18.3
\fIStandard attributes\fR
.sp 9p
.RT
.PP
The standard attribute types are listed in the first column of
Table\ 9/X.402. For each listed type, the second column indicates the character
sets \(em numeric, printable, and teletex \(em from which attribute values
may be
drawn.
.PP
Table 9/X.402 has three sections. Attribute types in the first are of a
general nature, those in the second have to do with \fIrouting to\fR a
PDS, and those in the third have to do with \fIaddressing within\fR a PDS.
.RT
.ce
\fBH.T. [T9.402]\fR
.ce
TABLE\ 9/X.402
.ce
\fBStandard attributes\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(120p) | cw(24p) sw(24p) sw(24p) , ^ | c | c | c.
Standard attribute type Character sets
NUM PRT TTX
_
.T&
lw(120p) | lw(24p) | lw(24p) | lw(24p) .
\fIGeneral\fR
.T&
lw(120p) | cw(24p) | cw(24p) | cw(24p) .
T{
administration\(hydomain\(hyname
T} \(mu \(mu \(em
.T&
lw(120p) | cw(24p) | cw(24p) | cw(24p) .
common\(hyname \(em \(mu \(mu
.T&
lw(120p) | cw(24p) | cw(24p) | cw(24p) .
country\(hyname \(mu \(mu \(em
.T&
lw(120p) | cw(24p) | cw(24p) | cw(24p) .
network\(hyaddress \(mu\|\ua\d\u)\d \(em \(em
.T&
lw(120p) | cw(24p) | cw(24p) | cw(24p) .
numeric\(hyuser\(hyidentifier \(mu \(em \(em
.T&
lw(120p) | cw(24p) | cw(24p) | cw(24p) .
organization\(hyname \(em \(mu \(mu
.T&
lw(120p) | cw(24p) | cw(24p) | cw(24p) .
T{
organizational\(hyunit\(hynames
T} \(em \(mu \(mu
.T&
lw(120p) | cw(24p) | cw(24p) | cw(24p) .
personal\(hyname \(em \(mu \(mu
.T&
lw(120p) | cw(24p) | cw(24p) | cw(24p) .
private\(hydomain\(hyname \(mu \(mu \(em
.T&
lw(120p) | cw(24p) | cw(24p) | cw(24p) .
terminal\(hyidentifier \(em \(mu \(em
.T&
lw(120p) | cw(24p) | cw(24p) | cw(24p) .
terminal\(hytype \(em \(em \(em
_
.T&
lw(120p) | cw(24p) | cw(24p) | cw(24p) .
\fIPostal routing\fR
.T&
lw(120p) | cw(24p) | cw(24p) | cw(24p) .
T{
physical\(hydelivery\(hyservice\(hyname
T} \(em \(mu \(em
.T&
lw(120p) | cw(24p) | cw(24p) | cw(24p) .
T{
physical\(hydelivery\(hycountry\(hyname
T} \(mu \(mu \(em
.T&
lw(120p) | cw(24p) | cw(24p) | cw(24p) .
postal\(hycode \(mu \(mu \(em
_
.T&
lw(120p) | cw(24p) | cw(24p) | cw(24p) .
\fIPostal addressing\fR
.T&
lw(120p) | cw(24p) | cw(24p) | cw(24p) .
T{
extension\(hypostal\(hyO/R\(hyaddress\(hycomponents
T} \(em \(mu \(mu
.T&
lw(120p) | cw(24p) | cw(24p) | cw(24p) .
T{
extension\(hyphysical\(hydelivery\(hyaddress\(hycomponents
T} \(em \(mu \(mu
.T&
lw(120p) | cw(24p) | cw(24p) | cw(24p) .
local\(hypostal\(hyattributes \(em \(mu \(mu
.T&
lw(120p) | cw(24p) | cw(24p) | cw(24p) .
T{
physical\(hydelivery\(hyoffice\(hyname
T} \(em \(mu \(mu
.T&
lw(120p) | cw(24p) | cw(24p) | cw(24p) .
T{
physical\(hydelivery\(hyoffice\(hynumber
T} \(em \(mu \(mu
.T&
lw(120p) | cw(24p) | cw(24p) | cw(24p) .
T{
physical\(hydelivery\(hyorganization\(hyname
T} \(em \(mu \(mu
.T&
lw(120p) | cw(24p) | cw(24p) | cw(24p) .
T{
physical\(hydelivery\(hypersonal\(hyname
T} \(em \(mu \(mu
.T&
lw(120p) | cw(24p) | cw(24p) | cw(24p) .
T{
post\(hyoffice\(hybox\(hyaddress
T} \(em \(mu \(mu
.T&
lw(120p) | cw(24p) | cw(24p) | cw(24p) .
poste\(hyrestante\(hyaddress \(em \(mu \(mu
.T&
lw(120p) | cw(24p) | cw(24p) | cw(24p) .
street\(hyaddress \(em \(mu \(mu
.T&
lw(120p) | cw(24p) | cw(24p) | cw(24p) .
T{
unformatted\(hypostal\(hyaddress
T} \(em \(mu \(mu
.T&
lw(120p) | cw(24p) | cw(24p) | cw(24p) .
unique\(hypostal\(hyname \(em \(mu \(mu
_
.T&
lw(120p) | lw(24p) | lw(24p) | lw(24p) .
NUM Numeric .parag PRT Printable .parag TTX Teletex .parag \(mu Permitted .parag
.T&
lw(120p) | lw(24p) | lw(24p) | lw(24p) .
T{
\ua\d\u)\d
Under prescribed circumstances a sequence of octet
strings
.parag
T}
.TE
.nr PS 9
.RT
.ad r
\fBTable 9/X.402 [T9.402], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.PP
The standard attribute types, summarized in Table 9/X.402, are
individually defined and described below.
.sp 1P
.LP
18.3.1
\fIAdministration\(hydomain\(hyname\fR
.sp 9p
.RT
.PP
An \fBadministration\(hydomain\(hyname\fR is a standard attribute that
identifies an ADMD relative to the country denoted by a country\(hyname.
.PP
The value of an administration\(hydomain\(hyname is a numeric or printable
string chosen from a set of such strings that is administered for this
purpose by the country alluded to above.
.PP
\fINote\fR \ \(em\ The attribute value comprising a single space (\*Q \*U)
shall be reserved for the following purpose. If permitted by the country
denoted by the country\(hyname attribute, a single space shall designate
any (i.e.,\ all) ADMDs
within the country. This affects both the identification of users within the
country and the routing of messages, probes, and reports to and among the
ADMDs of that country. Regarding the former, it requires that the O/R addresses
of
users within the country be chosen so as to ensure their unambiguousness,
even in the absence of the actual names of the users' ADMDs. Regarding
the latter, it permits both PRMDs within, and ADMDs outside of the country,
to route
messages, probes, and reports to any of the ADMDs within the country
indiscriminantly, and requires that the ADMDs within the country interconnect
themselves in such a way that the messages, probes, and reports are conveyed
to their destinations.
.RT
.sp 1P
.LP
18.3.2
\fICommon\(hyname\fR
.sp 9p
.RT
.PP
A \fBcommon\(hyname\fR is a standard attribute that identifies a user or
DL relative to the entity denoted by another attribute (e.g.,\ an
organization\(hyname).
.PP
The value of a common\(hyname is a printable string, teletex string, or
both. Whether printable or teletex, the string is chosen from a set of
such
strings that is administered for this purpose (and perhaps others) by the
entity alluded to above.
.PP
\fINote\fR \ \(em\ Among many other possibilities, a common\(hyname might
identify an organizational role (e.g.,\ \*QDirector of Marketing\*U).
.RT
.sp 1P
.LP
18.3.3
\fICountry\(hyname\fR
.sp 9p
.RT
.PP
A \fBcountry\(hyname\fR is a standard attribute that identifies a
country.
.PP
The value of a country\(hyname is a numeric string that gives one of the
numbers assigned to the country by Recommendation\ X.121, or a printable
string that gives the character pair assigned to the country by ISO\ 3166.
.RT
.sp 1P
.LP
18.3.4
\fIExtension\(hypostal\(hyO/R\(hyaddress\(hycomponents\fR
.sp 9p
.RT
.PP
An \fBextension\(hypostal\(hyO/R\(hyaddress\(hycomponents\fR is a standard
attribute that provides, in a postal address, additional information necessary
to identify the addressee (e.g.,\ an organizational unit).
.PP
The value of an extension\(hyO/R\(hyaddress\(hycomponents is a printable
string, teletex string, or both.
.RT
.sp 1P
.LP
18.3.5
\fIExtension\(hyphysical\(hydelivery\(hyaddress\(hycomponents\fR
.sp 9p
.RT
.PP
An \fBextension\(hyphysical\(hydelivery\(hyaddress\(hycomponents\fR is
a standard attribute that specifies, in a postal address, additional information
necessary to identify the exact point of delivery (e.g.,\ room and floor
numbers in a
large building).
.PP
The value of an extension\(hyphysical\(hydelivery\(hyaddress\(hycomponents is a
printable string, teletex string, or both.
.RT
.sp 1P
.LP
18.3.6
\fILocal\(hypostal\(hyattributes\fR
.sp 9p
.RT
.PP
A \fBlocal\(hypostal\(hyattributes\fR is a standard attribute that identifies
the locus of distribution, other than that denoted by a
physical\(hydelivery\(hyoffice\(hyname attribute (e.g.,\ a geographical
area), of a
user's physical messages.
.PP
The value of a local\(hypostal\(hyattributes is a printable string,
teletex string, or both.
.bp
.RT
.sp 1P
.LP
18.3.7
\fINetwork\(hyaddress\fR
.sp 9p
.RT
.PP
A \fBnetwork\(hyaddress\fR is a standard attribute that gives the network
address of a terminal.
.PP
The value of a network\(hyaddress is any one of the following:
.RT
.LP
a)
a numeric string governed by Recommendation X.121;
.LP
b)
two numeric strings governed by Recommendations E.163
and E.164;
.LP
c)
a PSAP address.
.PP
\fINote\fR \ \(em\ Among the strings admitted by Recommendation X.121 is
a telex number preceded by the telex escape digit\ (8).
.sp 1P
.LP
18.3.8
\fINumeric\(hyuser\(hyidentifier\fR
.sp 9p
.RT
.PP
A \fBnumeric\(hyuser\(hyidentifier\fR is a standard attribute that
numerically identifies a user relative to the ADMD denoted by an
administration\(hydomain\(hyname.
.PP
The value of a numeric\(hyuser\(hyidentifier is a numeric string chosen
from a set of such strings that is administered for this purpose by the
ADMD alluded to above.
.RT
.sp 1P
.LP
18.3.9
\fIOrganization\(hyname\fR
.sp 9p
.RT
.PP
An \fBorganization\(hyname\fR is a standard attribute that identifies an
organization. As a national matter, this identification may be either relative
to the country denoted by a country\(hyname (so that organization names
are unique within the country), or relative to the MD identified by a private\(hydomain\(hyname,
or an administration\(hydomain\(hyname, or both.
.PP
The value of an organization\(hyname is a printable string, teletex
string, or both. Whether printable or teletex, the string is chosen from
a set of such strings that is administered for this purpose (and perhaps
others) by the country or MD alluded to above.
.PP
\fINote\fR \ \(em\ In countries choosing country\(hywide unique organization\(hynames,
a national registration authority for organization\(hynames is required.
.RT
.sp 1P
.LP
18.3.10
\fIOrganizational\(hyunit\(hynames\fR
.sp 9p
.RT
.PP
An \fBorganizational\(hyunit\(hynames\fR is a standard attribute that
identifies one or more units (e.g.,\ divisions or departments) of the
organization denoted by an organization\(hyname, each unit but the first
being a sub\(hyunit of the units whose names precede it in the attribute.
.PP
The value of an organizational\(hyunit\(hynames is an ordered sequence of
printable strings, an ordered sequence of teletex strings, or both. Whether
printable or teletex, each string is chosen from a set of such strings
that is administered for this purpose (and perhaps others) by the organization
(or
encompassing unit) alluded to above.
.RT
.sp 1P
.LP
18.3.11
\fIPhysicel\(hydelivery\(hyservice\(hyname\fR
.sp 9p
.RT
.PP
A \fBphysical\(hydelivery\(hyservice\(hyname\fR is a standard attribute that
identifies a PDS relative to the\ ADMD denoted by an
administration\(hydomain\(hyname.
.PP
The value of a physical\(hydelivery\(hyservice\(hyname is a printable string
chosen from a set of such strings that is administered for this purpose
by the ADMD alluded to above.
.RT
.sp 1P
.LP
18.3.12
\fIPersonal\(hyname\fR
.sp 9p
.RT
.PP
A \fBpersonal\(hyname\fR is a standard attribute that identifies a person
relative to the entity denoted by another attribute (e.g.,\ an
organization\(hyname).
.PP
The value of a personal\(hyname comprises the following four pieces of
information, the first mandatory, the others optional:
.RT
.LP
a)
the person's surname;
.LP
b)
the person's given name;
.LP
c)
the initials of all of his names but his surname;
.LP
d)
his generation (e.g., \*QJr\*U).
.PP
The above information is supplied as printable strings, teletex
strings, or both.
.bp
.sp 1P
.LP
18.3.13
\fIPhysical\(hydelivery\(hycountry\(hyname\fR
.sp 9p
.RT
.PP
A \fBphysical\(hydelivery\(hycountry\(hyname\fR is a standard attribute that
identifies the country in which a user takes delivery of physical messages.
.PP
The value of a physical\(hydelivery\(hycountry\(hyname is subject to the
same constraints as is the value of a country\(hyname.
.RT
.sp 1P
.LP
18.3.14
\fIPhysical\(hydelivery\(hyoffice\(hyname\fR
.sp 9p
.RT
.PP
A \fBphysical\(hydelivery\(hyoffice\(hyname\fR is a standard attribute that
identifies the city, village, etc. in which is situated the post office
through which a user takes delivery of physical messages.
.PP
The value of a physical\(hydelivery\(hyoffice\(hyname is a printable string,
teletex string, or both.
.RT
.sp 1P
.LP
18.3.15
\fIPhysical\(hydelivery\(hyoffice\(hynumber\fR
.sp 9p
.RT
.PP
A \fBphysical\(hydelivery\(hyoffice\(hynumber\fR is a standard attribute that
distinguishes among several post offices denoted by a single
physical\(hydelivery\(hyoffice\(hyname.
.PP
The value of a physical\(hydelivery\(hyoffice\(hynumber is a printable
string, teletex string, or both.
.RT
.sp 1P
.LP
18.3.16
\fIPhysical\(hydelivery\(hyorganization\(hyname\fR
.sp 9p
.RT
.PP
A \fBphysical\(hydelivery\(hyorganization\(hyname\fR is a standard attribute
that identifies a postal patron's organization.
.PP
The value of a physical\(hydelivery\(hyorganization\(hyname is a printable
string, teletex string, or both.
.RT
.sp 1P
.LP
18.3.17
\fIPhysical\(hydelivery\(hypersonal\(hyname\fR
.sp 9p
.RT
.PP
A \fBphysical\(hydelivery\(hypersonal\(hyname\fR is a standard attribute that
identifies a postal patron.
.PP
The value of a physical\(hydelivery\(hypersonal\(hyname is a printable
string, teletex string, or both.
.RT
.sp 1P
.LP
18.3.18
\fIPost\(hyoffice\(hybox\(hyaddress\fR
.sp 9p
.RT
.PP
A \fBpost\(hyoffice\(hybox\(hyaddress\fR is a standard attribute that specifies
the number of the post office box by means of which a user takes delivery
of
physical messages.
.PP
The value of a postal\(hycode is a numeric or printable string chosen
from the set of such strings that is maintained and standardized for this
purpose by the postal administration of the country identified by a
physical\(hydelivery\(hycountry\(hyname attribute.
.RT
.sp 1P
.LP
18.3.19
\fIPostal\(hycode\fR
.sp 9p
.RT
.PP
A \fBpostal\(hycode\fR is a standard attribute that specifies the postal
code for the geographical area in which a user takes delivery of physical
messages.
.PP
The value of a postal\(hycode is a numeric or printable string chosen
from the set of such strings that is maintained and standardized for this
purpose by the postal administration of the country identified by a
physical\(hydelivery\(hycountry\(hyname attribute.
.RT
.sp 1P
.LP
18.3.20
\fIPoste\(hyrestante\(hyaddress\fR
.sp 9p
.RT
.PP
A \fBposte\(hyrestante\(hyaddress\fR is a standard attribute that specifies
the code that a user gives to a post office in order to collect the physical
messages that await delivery to him.
.PP
The value of a poste\(hyrestante\(hyaddress is a printable string, teletex
string, or both chosen from the set of such strings assigned for this purpose
by the post office denoted by a physical\(hydelivery\(hyoffice\(hyname
attribute.
.bp
.RT
.sp 1P
.LP
18.3.21
\fIPrivate\(hydomain\(hyname\fR
.sp 9p
.RT
.PP
A \fBprivate\(hydomain\(hyname\fR is a standard attribute that identifies
a PRMD. As a national matter, this identification may be either relative
to the country denoted by a country\(hyname (so that PRMD names are unique
within the
country), or relative to the ADMD identified by an administration\(hydomain\(hyname.
.PP
The value of a private\(hydomain\(hyname is a numeric or printable string
chosen from a set of such strings that is administered for this purpose
by the country or ADMD alluded to above.
.PP
\fINote\fR \ \(em\ In countries choosing country\(hywide unique PRMD names, a
national registration authority for private\(hydomain\(hynames is required.
.RT
.sp 1P
.LP
18.3.22
\fIStreet\(hyaddress\fR
.sp 9p
.RT
.PP
A \fBstreet\(hyaddress\fR is a standard attribute that specifies the
street address (e.g.,\ house number and street name and type (e.g.,\ \*QRoad\*U))
at which a user takes delivery of physical messages.
.PP
The value of a street\(hyaddress is a printable string, teletex string,
or both.
.RT
.sp 1P
.LP
18.3.23
\fITerminal\(hyidentifier\fR
.sp 9p
.RT
.PP
A \fBterminal\(hyidentifier\fR is a standard attribute that gives the
terminal identifier of a terminal (e.g.,\ a Telex answer back or a Teletex
terminal identifier).
.PP
The value of a terminal\(hyidentifier is a printable string.
.RT
.sp 1P
.LP
18.3.24
\fITerminal\(hytype\fR
.sp 9p
.RT
.PP
A \fBterminal\(hytype\fR is a standard attribute that gives the type of
a terminal.
.PP
The value of a terminal\(hytype is any one of the following: \fItelex,\fR
\fIteletex, G3\ facsimile, G4\ facsimile, IA5\ terminal\fR , and \fIvideotex\fR
.
.RT
.sp 1P
.LP
18.3.25
\fIUnformatted\(hypostal\(hyaddress\fR
.sp 9p
.RT
.PP
An \fBunformatted\(hypostal\(hyaddress\fR is a standard attribute that
specifies a user's postal address in free form.
.PP
The value of an unformatted\(hypostal address is a sequence of printable
strings, each representing a line of text, a single teletex string, lines
being separated as prescribed for such strings; or both.
.RT
.sp 1P
.LP
18.3.26
\fIUnique\(hypostal\(hyname\fR
.sp 9p
.RT
.PP
A \fBunique\(hypostal\(hyname\fR is a standard attribute that identifies
the point of delivery, other than that denoted by a street\(hyaddress,
post\(hyoffice\(hybox\(hyaddress, or poste\(hyrestante\(hyaddress, (e.g.,\
a building or
hamlet) of a user's physical messages.
.PP
The value of a unique\(hypostal\(hyname is a printable string, teletex
string, or both.
.RT
.sp 1P
.LP
18.4
\fIAttribute list equivalence\fR
.sp 9p
.RT
.PP
Several O/R addresses, and thus several attribute lists, may denote the
same user or DL. This multiplicity of O/R addresses results in part (but
not in full) from the following attribute list equivalence rules:
.RT
.LP
a)
The relative order of standard attributes is insignificant.
.LP
b)
Where the value of a standard attribute may be a numeric
string or an equivalent printable string, the choice between them shall be
considered insignificant.
.LP
\fINote\fR \ \(em\ This rule applies even to the country\(hyname standard
attribute, where the choice between X.121 or ISO\ 3166 forms shall be considered
insignificant, where X.121 allocates more than one number to a country,
the
significance of which number is used has not been standardized by this
Recommendation.
.LP
c)
Where the value of a standard attribute may be a printable string, an
equivalent teletex string, or both, the choice between the three
possibilities shall be considered insignificant.
.bp
.LP
d)
Where the value of a standard attribute may contain letters, the cases
of those letter shall be considered insignificant.
.LP
e)
In a domain\(hydefined attribute type or value, or in a
standard attribute value, all leading, all trailing, and all but one
consecutive embedded spaces shall be considered insignificant.
.PP
\fINote\ 1\fR \ \(em\ An MD may impose additional equivalence rules upon
the attributes it assigns to its own users and DLs. It might define, e.g.,\
rules
concerning punctuation characters in attribute values, the case of letters
in such values, or the relative order of domain\(hydefined attributes.
.PP
\fINote\ 2\fR \ \(em\ As a national matter, MDs may impose additional equivalence
rules regarding standard attributes whose values are given as teletex strings,
in particular, the rules for deriving the equivalent printable strings.
.RT
.sp 1P
.LP
18.5
\fIO/R address forms\fR
.sp 9p
.RT
.PP
Every user or DL is assigned one or more O/R addresses. An \fBO/R
address\fR is an attribute list that distinguishes one user from another and
identifies the user's point of access to the MHS or the DL's expansion point.
.PP
An O/R address may take any of the forms summarized in Table 10/X.402.
The first column of the table identifies the attributes available for the
construction of O/R addresses. For each O/R address form, the second column
indicates the attributes that may appear in such O/R addresses and their
grades (see also \(sc\ 18.6).
.PP
Table 10/X.402 has four sections. Attribute types in the first are
those of a general nature, attribute types in the second and third those
specific to physical delivery. The fourth section encompasses domain\(hydefined
attributes.
.RT
.PP
The forms of O/R address, summarized in Table 10/X.402 are
individually defined and described below.
.sp 1P
.LP
18.5.1
\fIMnemonic O/R address\fR
.sp 9p
.RT
.PP
A \fBmnemonic O/R address\fR is one that mnemonically identifies a user
or DL. It identifies an ADMD, and a user or DL relative to it.
.PP
A mnemonic O/R address comprises the following attributes:
.RT
.LP
a)
one country\(hyname and one administration\(hydomain\(hyname, which together
identify an ADMD;
.LP
b)
one private\(hydomain\(hyname, one organization\(hyname, one
organizational\(hyunit\(hynames, one personal\(hyname or common\(hyname,
or a combination of the above; and optionally one or more domain\(hydefined
attributes; which
together identify a user or DL relative to the ADMD in item\ a) above.
.sp 1P
.LP
18.5.2
\fINumeric O/R address\fR
.sp 9p
.RT
.PP
A \fBnumeric O/R address\fR is one that numerically identifies a user.
It identifies an ADMD, and a user relative to it.
.PP
A numeric O/R address comprises the following attributes:
.RT
.LP
a)
one country\(hyname and one administration\(hydomain\(hyname, which together
identify an ADMD;
.LP
b)
one numeric\(hyuser\(hyidentifier and, conditionally, one
private\(hydomain\(hyname, which together identify the user relative to
the ADMD in item a above;
.LP
c)
conditionally, one or more domain\(hydefined attributes which provide
information additional to that which identifies the user.
.sp 1P
.LP
18.5.3
\fIPostal O/R address\fR
.sp 9p
.RT
.PP
A \fBpostal O/R address\fR is one that identifies a user by means of
its postal address. It identifies the PDS through which the user is to be
accessed and gives the user's postal address.
.PP
The following kinds of postal O/R address are
distinguished:
.RT
.LP
a)
\fBformatted\fR ;: Said of a postal O/R address that specifies a user's
postal address by means of several attributes. For this form of postal
O/R address, this Recommendation prescribes the structure of postal addresses
in some detail;
.LP
b)
\fBunformatted\fR ;: Said of a postal O/R address that specifies a user's
postal address in a single attribute. For this form of postal O/R
address, this Recommendation largely does not prescribe the structure of
postal addresses.
.bp
.ce
\fBH.T. [T10.402]\fR
.ce
TABLE\ 10/X.402
.ce
\fBForms of O/R address\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(120p) | cw(24p) sw(24p) sw(12p) sw(12p) sw(24p) , ^ | c | c | c s
^ | ^ | ^ | ^ | ^ | c
^ | l | l | c | c | l.
Attribute type O/R address forms
MNEM NUMR POST TERM F U
_
.T&
lw(120p) | lw(24p) | lw(24p) | lw(12p) | lw(12p) | lw(24p) .
\fIGeneral\fR
.T&
lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
T{
administration\(hydomain\(hyname
T} M M M M C
.T&
lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
common\(hyname C \(em \(em \(em \(em
.T&
lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
country\(hyname M M M M C
.T&
lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
network\(hyaddress \(em \(em \(em \(em M
.T&
lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
numeric\(hyuser\(hyidentifier \(em M \(em \(em \(em
.T&
lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
organization\(hyname C \(em \(em \(em \(em
.T&
lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
T{
organizational\(hyunit\(hynames
T} C \(em \(em \(em \(em
.T&
lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
personal\(hyname C \(em \(em \(em \(em
.T&
lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
private\(hydomain\(hyname C C C C C
.T&
lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
terminal\(hyidentifier \(em \(em \(em \(em C
.T&
lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
terminal\(hyidentifier \(em \(em \(em \(em C
_
.T&
lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
\fIPostal routing\fR
.T&
lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
T{
physical\(hydelivery\(hyservice
T} \(em \(em C C \(em
.T&
lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
T{
physical\(hydelivery\(hycountry\(hyname
T} \(em \(em M M \(em
.T&
lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
postal\(hycode \(em \(em M M \(em
_
.T&
lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
\fIPostal addressing\fR
.T&
lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
T{
extension\(hypostal\(hyO/R\(hyaddress\(hycomponents
T} \(em \(em C \(em \(em
.T&
lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
T{
extension\(hyphysical\(hydelivery\(hyaddress\(hycomponents
T} \(em \(em C \(em \(em
.T&
lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
local\(hypostal\(hyattributes \(em \(em C \(em \(em
.T&
lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
T{
physical\(hydelivery\(hyoffice\(hyname
T} \(em \(em C \(em \(em
.T&
lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
T{
physical\(hydelivery\(hyoffice\(hynumber
T} \(em \(em C \(em \(em
.T&
lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
T{
physical\(hydelivery\(hyorganization\(hyname
T} \(em \(em C \(em \(em
.T&
lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
T{
physical\(hydelivery\(hypersonal\(hyname
T} \(em \(em C \(em \(em
.T&
lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
T{
poste\(hyoffice\(hybox\(hyaddress
T} \(em \(em C \(em \(em
.T&
lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
poste\(hyrestante\(hyaddress \(em \(em C \(em \(em
.T&
lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
street address \(em \(em C \(em \(em
.T&
lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
T{
unformatted\(hypostal\(hyaddress
T} \(em \(em \(em M \(em
.T&
lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
unique\(hypostal\(hyname \(em \(em C \(em \(em
_
.T&
lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
\fIDomain\(hydefined\fR
.T&
lw(120p) | cw(24p) | cw(24p) | cw(12p) | cw(12p) | cw(24p) .
T{
domain\(hydefined (one or more)
T} C C \(em \(em C
_
.T&
lw(72p) | lw(144p) .
T{
MNEM
Mnemonic
NUMR
Numeric
POST
Postal
TERM
Terminal
T} T{
F
Formatted
U
Unformatted
M
Mandatory
C
Conditional
.parag
T}
.TE
.nr PS 9
.RT
.ad r
\fBTable 10/X.402 [T10.402], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.PP
A postal O/R address, whether formatted or unformatted, comprises the following
attributes:
.LP
a)
one country\(hyname and one administration\(hydomain\(hyname, which together
identify an ADMD;
.LP
b)
conditionally, one private\(hydomain\(hyname, one
physical\(hydelivery\(hyservice\(hyname, or both, which together identify
the PDS
by means of which the user is to be accessed;
.LP
c)
one physical\(hydelivery\(hycountry\(hyname and one postal\(hycode,
which together identify the geographical region in which the user takes
delivery of physical messages.
.PP
A formatted postal O/R address comprises, additionally, one of
each postal addressing attribute (see Table\ 9B/FX.402), except
unformatted\(hypostal\(hyaddress, that the PDS requires to identify the postal
patron.
.PP
An unformatted postal O/R address comprises, additionally, one
unformatted\(hypostal\(hyaddress attribute.
.PP
\fINote\fR \ \(em\ The total number of characters in the values of all
attributes but country\(hyname, administration\(hydomain\(hyname, and
physical\(hydelivery\(hyservice\(hyname in a postal O/R address should
be small enough to permit their rendition in 6\ lines of 30\ characters,
the size of a typical
physical envelope window. The rendition algorithm is PDAU\(hyspecific but is
likely to include inserting delimiters (e.g.,\ spaces) between some attribute
values.
.RT
.sp 1P
.LP
18.5.4
\fITerminal O/R address\fR
.sp 9p
.RT
.PP
A \fBterminal OB/FR address\fR is one that identifies a user by means of
the network address and, if required, the type of his terminal. It may
also
identify the ADMD through which that terminal is accessed. In the case of a
telematic terminal, it gives the terminal's network address and possibly its
terminal identifier and terminal type. In the case of a telematic terminal,
it gives the terminal's network address and possibly its terminal identifier
and terminal type. In the case of a telex terminal, it gives its telex
number.
.PP
A terminal O/R address comprises the following attributes:
.RT
.LP
a)
one network\(hyaddress;
.LP
b)
conditionally, one terminal\(hyidentifier;
.LP
c)
conditionally, one terminal\(hytype;
.LP
d)
conditionally, both one country\(hyname and one
administration\(hydomain\(hyname which together identify an ADMD;
.LP
e)
conditionally, one private\(hydomain\(hyname and, conditionally, one
or more domain\(hydefined attributes, all of which provide information
additional to that which identifies the user.
.PP
The private\(hydomain\(hyname and the domain\(hydefined attributes shall
be present only if the country\(hyname and administration\(hydomain\(hyname
attributes are present.
.sp 1P
.LP
18.6
\fIConditional attributes\fR
.sp 9p
.RT
.PP
The presence or absence in a particular O/R address of the
attributes marked conditional in Table\ 10B/FX.402 is determined as follows.
.PP
If a user or DL is accessed through a PRMD, attributes used to route messages
to the PRMD are present in the O/R address at the discretion of, and in
accordance with rules established by the ADMD denoted by the country\(hyname
and administration\(hydomain\(hyname attributes of the O/R address. The
ADMD imposes no other constraints on the attributes in the O/R address.
If a user is not
accessed through a PRMD, all conditional attributes except those specific to
postal O/R addresses are present in an O/R address at the discretion of,
and in accordance with rules established by, the ADMD denoted by the country\(hyname
and administration\(hydomain\(hyname attributes.
.PP
All conditional attributes specific to postal O/R addresses are
present or absent in such O/R addresses so as to satisfy the postal addressing
requirements of the users they identify.
.RT
.sp 2P
.LP
\fB19\fR \fBRouting\fR
.sp 1P
.RT
.PP
To convey a message, probe, or report toward a user or the
expansion point of a DL, an MTA must not only locate the user or DL
(i.e.,\ obtain its O/R address) but also select a route to that location.
.PP
External routing is an incremental and only loosely standardized
process. Suggested below are several principles of external routing. Internal
routing is outside the scope of this Recommendation.
.bp
.PP
The following principles are illustrative, not definitive:
.RT
.LP
a)
In an MHS that comprises a single MD, of course, routing is not an issue.
.LP
b)
A PRMD may be connected to a single, ADMD. When this is so, routing always
involves the ADMD necessarily.
.LP
c)
An ADMD may be connected to multiple PRMDs. When this is so, routing
may be based upon conditional O/R address attributes, including but not
limited to private\(hydomain\(hyname.
.LP
d)
An MD may be directly connected to some but not all other
MDs. When the O/R address identifies a MD to which no direct connection
exists, routing may be based upon \fIbilateral agreements\fR with the MDs
to which direct connections do exist and other local rules.
.LP
e)
When the MD is directly connected to the MD identified by
the O/R address, the object is typically routed to that MD directly.
.LP
f)
By \fIbilateral agreement\fR , one MD might route an object to
another MD for the purpose, e.g.,\ of conversion.
.LP
g)
An MD may route to a malformed O/R address provided (of
course) that it contains at least the attributes required to do so.
.PP
\fINote\fR \ \(em\ The bilateral agreements and local rules
alluded to above are beyond the
scope of this Recommendation and may be based upon technical, policy, economic,
or other considerations.
.LP
SECTION\ 5\ \(em\
USE OF THE DIRECTORY
.sp 1P
.RT
.sp 2P
.LP
\fB20\fR \fBOverview\fR
.sp 1P
.RT
.PP
This section describes the uses to which the MHS may put the
Directory if it is present. If the Directory is unavailable to the MHS,
how, if at all, the MHS performs these same tasks is a local matter.
.PP
This section covers the following topics:
.RT
.LP
a)
authentication;
.LP
b)
name resolution;
.LP
c)
DL expansion;
.LP
d)
capability assessment.
.sp 2P
.LP
\fB21\fR \fBAuthentication\fR
.sp 1P
.RT
.PP
A functional object may accomplish authentication
using information stored in
the Directory.
.RT
.sp 2P
.LP
\fB22\fR \fBName resolution\fR
.sp 1P
.RT
.PP
A functional object may accomplish name resolution using the
Directory.
.PP
To obtain the O/R address(es) of a user or DL whose Directory name it possesses,
an object presents that name to the Directory and requests from the object's
Directory entry the following attributes:
.RT
.LP
a)
\fIMHS O/R addresses\fR ;
.LP
b)
\fIMHS preferred delivery methods\fR
.PP
To do this successfully, the object must first authenticate itself to the
Directory and have access rights to the information requested.
.bp
.sp 2P
.LP
\fB23\fR \fBDL expansion\fR
.sp 1P
.RT
.PP
A functional object may accomplish DL expansion using the
Directory, first verifying that the necessary submit permissions exist.
.PP
To obtain the members of a DL whose Directory name it possesses, the object
presents that name to the Directory and requests from the object's
Directory entry the following attributes:
.RT
.LP
a)
\fIMHS DL members\fR ;
.LP
b)
\fIMHS DL submit permissions\fR ;
.LP
c)
\fIMHS preferred delivery methods\fR .
.PP
To do this successfully, the MTA must first authenticate itself to the
Directory and have access rights to the information requested.
.sp 2P
.LP
\fB24\fR \fBCapability assessment\fR
.sp 1P
.RT
.PP
A functional object may assess the capabilities of a user or MS
using the Directory.
.PP
The following Directory attributes represent user capabilities of
possible significance in message handling:
.RT
.LP
a)
\fIMHS deliverable content length\fR ;
.LP
b)
\fIMHS deliverable content types\fR ;
.LP
c)
\fIMHS deliverable EITs\fR ;
.LP
d)
\fIMHS preferred delivery methods\fR .
.PP
The following Directory attributes represent MS capabilities of
possible significance in message handling:
.LP
a)
\fIMHS supported automatic actions\fR ;
.LP
b)
\fIMHS supported content types\fR ;
.LP
c)
\fIMHS supported optional attributes\fR .
.PP
To assess a particular capability of a user or MS whose Directory name
it possesses, the object presents that name to the Directory and requests
from the object's Directory entry the attribute associated with that
capability.
.PP
To do this successfully, the MTA must first authenticate itself to the
Directory and have access rights to the information requested.
.RT
.LP
SECTION\ 6\ \(em\ OSI REALIZATION
.sp 1P
.RT
.sp 2P
.LP
\fB25\fR \fBOverview\fR
.sp 1P
.RT
.PP
This section describes how the MHS is realized by means of OSI.
.PP
This section covers the following topics:
.RT
.LP
a)
application service elements;
.LP
b)
application contexts.
.sp 2P
.LP
\fB26\fR \fBApplication service elements\fR
.sp 1P
.RT
.PP
This paragraph identifies the application service elements\fR (ASEs) that
figure in the OSI realization of message handling.
.PP
In OSI the communication capabilities of open systems are organized
into groups of related capabilities called ASEs. The present clause reviews
this concept from the OSI reference model, draws a distinction between
\fIsymmetric\fR and \fIasymmetric\fR ASEs, and introduces the ASEs defined
for or
supportive of Message Handling.
.PP
\fINote\fR \ \(em\ Besides the ASEs discussed, the MHS relies upon the
Directory access service element defined in Recommendation\ X.519. However,
since that
ASE does not figure in the ACs for message handling (see Recommendation\
X.419), it is not discussed here.
.bp
.RT
.sp 1P
.LP
26.1
\fIThe ASE concept\fR
.sp 9p
.RT
.PP
The ASE concept is illustrated in Figure 12B/FX.402, which depicts
two communicating open systems. Only the OSI\(hyrelated portions of the open
systems, called AEs, are shown. Each AE comprises a UE and one or more
ASEs. A UE represents the controlling or organizing portion of an AE which
defines the open system's role (e.g.,\ that of an MTA). An ASE represents
one of the
communication capability sets, or services (e.g.,\ for message submission or
transfer), that the UE requires to play its role.
.PP
The relationship between two AEs in different open systems is called an
application association. The ASEs in each open system communicate with
their peer ASEs in the other open system via a presentation connection
between them. That communication is what creates and sustains the relationship
embodied in
the application association. For several ASEs to be successfully combined
in a single AE, they must be designed to coordinate their use of the application
association.
.RT
.LP
.rs
.sp 21P
.ad r
\fBFigure 12/X.402, p.\fR
.sp 1P
.RT
.ad b
.RT
.PP
An ASE plays the largely mechanical role of translating requests and responses
made by its UE to and from the form dictated by the application protocol
that governs the ASE's interaction with its peer ASE in the open
system to which the association connects it. The ASE realizes an abstract
service, or a part thereof, for purposes of OSI communication (see
Recommendation\ X.407).
.PP
\fINote\fR \ \(em\ Strictly speaking, an open system's role is determined
by the behaviour of its application processes. In the message handling
context an
application process realizes a functional object of one of the types defined
in \(sc\ 7. A UE in turn is one part of an application process.
.RT
.sp 1P
.LP
26.2
\fISymmetric and asymmetric ASEs\fR
.sp 9p
.RT
.PP
The following two kinds of ASE, illustrated in Figure 13/X.402, can be
distinguished:
.RT
.LP
a)
\fBsymmetric\fR : Said of an ASE by means of which a UE both supplies
and consumes a service. The ASE for message transfer, e.g.,\ is
symmetric because both open systems, each of which embodies an MTA, offer
and may consume the service of message transfer by means of it.
.LP
b)
\fBasymmetric\fR : Said of an ASE by means of which a UE
supplies or consumes a service, but not both, depending upon how the ASE is
configured. The ASE for message delivery, e.g.,\ is asymmetric because
only the open system embodying an MTA offers the associated service and
only the other open system, which embodies a UA or MS, consumes it.
.bp
.LP
.rs
.sp 16P
.ad r
\fBFigure 13/X.402, p.\fR
.sp 1P
.RT
.ad b
.RT
.PP
With respect to a particular asymmetric ASE, one UE supplies a
service which the other consumes. The ASEs co\(hylocated with the UEs assist in
the service's supply and consumption. The resulting four roles are captured
in Figure\ 14/X.402 and in the following terminology:
.LP
a)
\fBx\(hysupplying UE\fR : An application process that supplies the service
represented by asymmetric ASE\ x.
.LP
b)
\fBx\(hysupplying ASE\fR : An asymmetric ASE\ x configured for
co\(hylocation with an x\(hysupplying\(hyUE.
.LP
c)
\fBx\(hyconsuming UE\fR : An application process that consumes the service
represented by asymmetric ASE\ x.
.LP
d)
\fBx\(hyconsuming ASE\fR : An asymmetric ASE x configured for
co\(hylocation with an x\(hyconsuming\(hyUE.
.LP
.rs
.sp 22P
.ad r
\fBFigure 14/X.402, p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.PP
As indicated, the four roles described above are defined relative to a
particular ASE. When an AE comprises several asymmetric ASEs, these roles
are assigned independently for each ASE. Thus, as shown in Figure\ 15/X.402,
a single UE might serve as the consumer with respect to one ASE and as
the
supplier with respect to another.
.LP
.rs
.sp 19P
.ad r
\fBFigure 15/X.402, p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
26.3
\fIMessage handling ASEs\fR
.sp 9p
.RT
.PP
The ASEs that provide the various message handling services are
listed in the first column of Table\ 11/X.402. For each ASE listed, the
second column indicates whether it is symmetric or asymmetric. The third
column
identifies the functional objects \(em UAs, MSs, MTAs, and AUs \(em that are
associated with the ASE, either as consumer or as supplier.
.RT
.ce
\fBH.T. [T11.402]\fR
.ce
TABLE\ 11/X.402
.ce
\fBMessage handling ASEs\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(30p) | cw(30p) | cw(24p) sw(24p) sw(24p) sw(24p) , ^ | ^ | c | c | c | c.
ASE Form Functional objects
UA MS MTA AU
_
.T&
lw(30p) | lw(30p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) .
MTSE SY \(em \(em CS \(em
_
.T&
lw(30p) | lw(30p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) .
MSSE ASY C CS S \(em
.T&
lw(30p) | lw(30p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) .
MDSE ASY C C\fBS\fR S \(em
.T&
lw(30p) | lw(30p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) .
MRSE ASY C S\fBS\fR \(em \(em
.T&
lw(30p) | lw(30p) | cw(24p) | cw(24p) | cw(24p) | cw(24p) .
MASE ASY C CS S \(em
_
.T&
lw(30p) | lw(30p) | lw(24p) | lw(24p) | cw(24p) | cw(24p) .
SY Symmetric .parag ASY Asymmetric .parag C Consumer .parag S Supplier .parag
.TE
.nr PS 9
.RT
.ad r
\fBTable 11/X.402 [T11.402], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.PP
The message handling ASEs, summarized in Table 11/X.402, are
individually introduced in the clauses below. Each is defined in
Recommendation\ X.419.
.sp 1P
.LP
26.3.1
\fIMessage transfer\fR
.sp 9p
.RT
.PP
The message transfer service element (MTSE) is the means by which the transfer
transmittal step is effected.
.RT
.sp 1P
.LP
26.3.2
\fIMessage submission\fR
.sp 9p
.RT
.PP
The message submission service element (MSSE) is the means by
which the submission transmittal step is effected.
.RT
.sp 1P
.LP
26.3.3
\fIMessage delivery\fR
.sp 9p
.RT
.PP
The message delivery service element (MDSE) is the means by which the delivery
transmittal step is effected.
.RT
.sp 1P
.LP
26.3.4
\fIMessage retrieval\fR
.sp 9p
.RT
.PP
The message retrieval service element (MRSE) is the means by
which the retrieval transmittal step is effected.
.RT
.sp 1P
.LP
26.3.5
\fIMessage administration\fR
.sp 9p
.RT
.PP
The message administration service element (MASE) is the means by which
a UA, MS, or MTA places on file with one another information that enables
and controls their subsequent interaction by means of the MSSE, MDSE, MRSE,
and MASE.
.RT
.sp 1P
.LP
26.4
\fISupporting ASEs\fR
.sp 9p
.RT
.PP
The general\(hypurpose ASEs upon which message handling ASEs depend
are listed in the first column of Table\ 12/X.402. For each listed ASE, the
second column indicates whether it is symmetric or asymmetric.
.RT
.ce
\fBH.T. [T12.402]\fR
.ce
TABLE\ 12/X.402
.ce
\fBSupporting ASEs\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(66p) | cw(66p) .
ASE Form
_
.T&
cw(66p) | cw(66p) .
ROSE SY
.T&
cw(66p) | cw(66p) .
RTSE SY
.T&
cw(66p) | cw(66p) .
ACSE SY
_
.T&
lw(66p) | cw(66p) .
SY Symmetric .parag
.TE
.nr PS 9
.RT
.ad r
\fBTable 12/X.402 [T12.402], p.\fR
.sp 1P
.RT
.ad b
.RT
.PP
.sp 1
The supporting ASEs, summarized in Table 12/X.402 are individually introduced
below.
.sp 1P
.LP
26.4.1
\fIRemote operations\fR
.sp 9p
.RT
.PP
The remote operations service element (ROSE) is the means by
which the asymmetric Message Handling ASEs structure their request\(hyresponse
interactions between consuming and supplying open systems.
.PP
The ROSE is defined in Recommendation X.219.
.bp
.RT
.sp 1P
.LP
26.4.2
\fIReliable transfer\fR
.sp 9p
.RT
.PP
The reliable transfer service element (RTSE) is the means by
which various symmetric and asymmetric message handling ASEs convey information
objects \(em especially large ones (e.g.,\ facsimile messages) \(em between
open
systems so as to ensure their safe\(hystorage at their destinations.
.PP
The RTSE is defined in Recommendation X.218.
.RT
.sp 1P
.LP
26.4.3
\fIAssociation control\fR
.sp 9p
.RT
.PP
The association control service element (ACSE) is the means by
which all application associations between open systems are established,
released, and in other respects managed.
.PP
The ACSE is defined in Recommendation X.217.
.RT
.sp 2P
.LP
\fB27\fR \fBApplication contexts\fR
.sp 1P
.RT
.PP
In OSI the communication capabilities (i.e., ASEs) of two open
systems are marshalled for a particular purpose by means of application
contexts (ACs). An AC is a detailed specification of the use of an association
between two open systems, i.e., a protocol.
.PP
An AC specifies how the association is to be established (e.g., what
initialization parameters are to be exchanged), what ASEs are to engage in
peer\(hyto\(hypeer communication over the association, what constraints
(if any) are to be imposed upon their individual use of association, whether
the initiator or responder is the consumer of each asymmetric ASE, and
how the association is to be released (e.g., what finalization parameters
are to be exchanged).
.PP
Every AC is named (by an ASN.1 object identifier). The initiator of an
association indicates to the responder the AC that will govern the
association's use by conveying the AC's name to it by means of the ACSE.
.PP
An AC also identifies by name (an ASN.1 object identifier) the
abstract syntaxes of the APDUs that an association may carry as a result
of its use by the AC's ASEs. Conventionally one assigns a name to the set
of APDUs
associated either with each individual ASE or with the AC as a whole. The
initiator of an association indicates to the responder the one or more
abstract syntaxes associated with the AC by conveying their names to it
via the ACSE.
.PP
The abstract syntax of an APDU is its structure as an information
object (e.g.,\ an ASN.1 Set comprising an Integer command code and an IA5
String command argument). It is distinguished from the APDU's transfer
syntax which is how the information object is represented for transmission
between two open
systems (e.g.,\ one octet denoting an ASN.1 Set, followed by one octet giving
the length of the Set,\ etc.).
.PP
The ACs by means of which the various message handling services are
provided are specified in Recommendation\ X.419. These protocols are known as
P1, P3, and P7.
.PP
\fINote\fR \ \(em\ The nature of a message's content does not enter into the
definition of message handling ACs because the content is encapsulated
(as an octet string) in the protocols by means of which it is conveyed.
\v'1P'
.RT
.ce 1000
ANNEX\ A
.ce 0
.ce 1000
(to Recommendation X.402)
.sp 9p
.RT
.ce 0
.ce 1000
\fBDirectory object classes and attributes\fR
.sp 1P
.RT
.ce 0
.PP
This Annex is an integral part of this Recommendation.
.sp 1P
.RT
.PP
Several Directory object classes, attributes, and attribute
syntaxes are specific to Message Handling. These are defined in the present
Annex using the OBJECT\(hyCLASS, ATTRIBUTE, and ATTRIBUTE\(hySYNTAX macros of
Recommendation X.501, respectively.
.bp
.sp 1P
.LP
A.1
\fIObject classes\fR
.sp 9p
.RT
.PP
The object classes specific to message handling
are those specified below.
.PP
\fINote\fR \ \(em\ The Directory object classes described in this Annex
can be combined with other object classes, eg., the ones defined in
Recommendation\ X.521. See also Recommendation\ X.501, \(sc\ 9, for an
explanation of how Directory object classes can be combined in one Directory
entry. Annex\ B of Recommendation\ X.521 gives some further information
about Directory name forms and possible Directory information tree structures.
.RT
.sp 1P
.LP
A.1.1
\fIMHS distribution list\fR
.sp 9p
.RT
.PP
An \fBMHS distribution list\fR object is a DL. The attributes in
its entry identify its common name, submit permissions, and O/R addresses
and, to the extent that the relevant attributes are present, describe the
DL,
identify its organization, organizational units, and owner; cite related
objects; and identify its deliverable content types, deliverable EITs,
members, and preferred delivery methods.
.RT
.LP
mhs\(hydistribution\(hylist OBJECT\(hyCLASS
.LP
SUBCLASS OF top
.LP
MUST CONTAIN\|{
.LP
commonName,
.LP
mhs\(hydl\(hysubmit\(hypermissions,
.LP
mhs\(hyor\(hyaddresses}
.LP
MAY CONTAIN\|{
.LP
description,
.LP
organization,
.LP
organizationalUnitName,
.LP
owner,
.LP
seeAlso,
.LP
mhs\(hydeliverable\(hycontent\(hytypes,
.LP
mhs\(hydeliverable\(hyeits,
.LP
mhs\(hydl\(hymembers,
.LP
mhs\(hypreferred\(hydelivery\(hymethods\|}
.LP
::= id\(hyoc\(hymhs\(hydistribution\(hylist
.sp 1P
.LP
A.1.2
\fIMHS message store\fR
.sp 9p
.RT
.PP
An \fBMHS message store\fR object is an AE that realizes an MS. The
attributes in its entry, to the extent that they are present, describe
the MS, identify its owner, and enumerate the optional attributes, automatic
actions, and content types it supports.
.RT
.LP
mhs\(hymessage\(hystore OBJECT\(hyCLASS
.LP
SUBCLASS OF applicationEntity
.LP
MAY CONTAIN\|{
.LP
description,
.LP
owner,
.LP
mhs\(hysupported\(hyoptional\(hyattributes,
.LP
mhs\(hysupported\(hyautomatic\(hyactions,
.LP
mhs\(hysupported\(hycontent\(hytypes\|}
.LP
::= id\(hyoc\(hymhs\(hymessage\(hystore
.sp 1P
.LP
A.1.3
\fIMHS message transfer agent\fR
.sp 9p
.RT
.PP
An \fBMHS message transfer agent\fR object is an AE that implements an
MTA. The attributes in its entry, to the extent that they are present,
describe the MTA and identify its owner and its deliverable content length.
.RT
.LP
mhs\(hymessage\(hytransfer\(hyagent OBJECT\(hyCLASS
.LP
SUBCLASS OF applicationEntity
.LP
MAY CONTAIN\|{
.LP
description,
.LP
owner,
.LP
mhs\(hydeliverable\(hycontent\(hylength\|}
.LP
::= id\(hyoc\(hymhs\(hymessage\(hytransfer\(hyagent
.bp
.sp 1P
.LP
A.1.4
\fIMHS user\fR
.sp 9p
.RT
.PP
An \fBMHS user\fR object is a generic MHS user. (The generic MHS user can
have, for example, a business address, a residential address, or both.)
The attributes in its entry identify the user's O/R address and, to the
extent that the relevant attributes are present, identify the user's deliverable
content
length, content types, and EITs; its MS; and its preferred delivery
methods.
.RT
.LP
mhs\(hyuser OBJECT\(hyCLASS
.LP
SUBCLASS OF top
.LP
MUST CONTAIN\|{
.LP
mhs\(hyor\(hyaddresses\|}
.LP
MAY CONTAIN\|{
.LP
mhs\(hydeliverable\(hycontent\(hylength,
.LP
mhs\(hydeliverable\(hycontent\(hytypes,
.LP
mhs\(hydeliverable\(hyeits,
.LP
mhs\(hymessage\(hystore,
.LP
mhs\(hypreferred\(hydelivery\(hymethods\|}
.LP
::= id\(hyoc\(hymhs\(hyuser
.sp 1P
.LP
A.1.5
\fIMHS user agent\fR
.sp 9p
.RT
.PP
An \fBMHS user agent\fR object is an AE that realizes a UA. The
attributes in its entry, to the extent that they are present, identify
the UA's owner; its deliverable content length, content types, and EITs;
and its O/R
address.
.RT
.LP
mhs\(hyuser\(hyagent OBJECT\(hyCLASS
.LP
SUBCLASS OF applicationEntity
.LP
MAY CONTAIN\|{
.LP
owner,
.LP
mhs\(hydeliverable\(hycontent\(hylength,
.LP
mhs\(hydeliverable\(hycontent\(hytypes,
.LP
mhs\(hydeliverable\(hyeits,
.LP
mhs\(hyor\(hyaddresses\|}
.LP
::= id\(hyoc\(hymhs\(hyuser\(hyagent
.sp 1P
.LP
A.2
\fIAttributes\fR
.sp 9p
.RT
.PP
The attributes specific to message handling are those specified
below.
.RT
.sp 1P
.LP
A.2.1
\fIMHS deliverable content length\fR
.sp 9p
.RT
.PP
The \fBMHS deliverable content length\fR attribute identifies the
maximum content length of the messages whose delivery a user will accept.
.PP
A value of this attribute is an Integer.
.RT
.LP
mhs\(hydeliverable\(hycontent\(hylength ATTRIBUTE
.LP
WITH ATTRIBUTE\(hySYNTAX integerSyntax
.LP
SINGLE VALUE
.LP
::= id\(hyat\(hymhs\(hydeliverable\(hycontent\(hylength
.sp 1P
.LP
A.2.2
\fIMHS deliverable content types\fR
.sp 9p
.RT
.PP
The \fBMHS deliverable content types\fR attribute identifies the
content types of the messages whose delivery a user will accept.
.PP
A value of this attribute is an object identifier.
.RT
.LP
mhs\(hydeliverable\(hycontent\(hytypes ATTRIBUTE
.LP
WITH ATTRIBUTE\(hySYNTAX objectIdentifierSyntax
.LP
MULTI VALUE
.LP
::= id\(hyat\(hymhs\(hydeliverable\(hycontent\(hytypes
.bp
.sp 1P
.LP
A.2.3
\fIMHS deliverable EITs\fR
.sp 9p
.RT
.PP
The \fBMHS deliverable EITs\fR attribute identifies the EITs of the
messages whose delivery a user will accept.
.PP
A value of this attribute is an object identifier.
.RT
.LP
mhs\(hydeliverable\(hyeits ATTRIBUTE
.LP
WITH ATTRIBUTE\(hySYNTAX objectIdentifierSyntax
.LP
MULTI VALUE
.LP
::= id\(hyat\(hymhs\(hydeliverable\(hyeits
.sp 1P
.LP
A.2.4
\fIMHS DL members\fR
.sp 9p
.RT
.PP
The \fBMHS DL members\fR attribute identifies a DL's members.
.PP
A value of this attribute is an O/R name.
.RT
.LP
mhs\(hydl\(hymembers ATTRIBUTE
.LP
WITH ATTRIBUTE\(hySYNTAX mhs\(hyor\(hyname\(hysyntax
.LP
MULTI VALUE
.LP
::= id\(hyat\(hymhs\(hydl\(hymembers
.sp 1P
.LP
A.2.5
\fIMHS DL submit permissions\fR
.sp 9p
.RT
.PP
The \fBMHS DL submit permissions\fR attribute identifies the users and
DLs that may submit messages to a DL.
.PP
A value of this attribute is a DL submit permission.
.RT
.LP
mhs\(hydl\(hysubmit\(hypermissions ATTRIBUTE
.LP
WITH ATTRIBUTE\(hySYNTAX mhs\(hydl\(hysubmit\(hypermission\(hysyntax
.LP
MULTI VALUE
.LP
::= id\(hyat\(hymhs\(hydl\(hysubmit\(hypermissions
.sp 1P
.LP
A.2.6
\fIMHS message store\fR
.sp 9p
.RT
.PP
The \fBMHS message store\fR attribute identifies a user's MS by name.
.PP
The value of this attribute is a Directory distinguished name.
.RT
.LP
mhs\(hymessage\(hystore ATTRIBUTE
.LP
WITH ATTRIBUTE\(hySYNTAX distinguishedNameSyntax
.LP
SINGLE VALUE
.LP
::= id\(hyat\(hymhs\(hymessage\(hystore
.sp 1P
.LP
A.2.7
\fIMHS O/R addresses\fR
.sp 9p
.RT
.PP
The \fBMHS O/R addresses\fR attribute specifies a user's or DL's O/R
addresses.
.PP
A value of this attribute is an O/R address.
.RT
.LP
mhs\(hyor\(hyaddresses ATTRIBUTE
.LP
WITH ATTRIBUTE\(hySYNTAX mhs\(hyor\(hyaddress\(hysyntax
.LP
MULTI VALUE
.LP
::= id\(hyat\(hymhs\(hyor\(hyaddresses
.sp 1P
.LP
A.2.8
\fIMHS preferred delivery methods\fR
.sp 9p
.RT
.PP
The \fBMHS preferred delivery methods\fR attribute identifies, in order
of decreasing preference, the methods of delivery a user prefers.
.PP
A value of this attribute is a preferred delivery method.
.RT
.LP
mhs\(hypreferred\(hydelivery\(hymethods ATTRIBUTE
.LP
WITH ATTRIBUTE\(hySYNTAX RequestedDeliveryMethod
.LP
MATCHES FOR EQUALITY
.LP
SINGLE VALUE
.LP
::= id\(hyat\(hymhs\(hypreferred\(hydelivery\(hymethods
.bp
.sp 1P
.LP
A.2.9
\fIMHS supported automatic actions\fR
.sp 9p
.RT
.PP
The \fBMHS supported automatic actions\fR attribute identifies the
automatic actions that an MS fully supports.
.PP
A value of this attribute is an object identifier.
.RT
.LP
mhs\(hysupported\(hyautomatic\(hyactions ATTRIBUTE
.LP
WITH ATTRIBUTE\(hySYNTAX objectIdentifierSyntax
.LP
MULTI VALUE
.LP
::= id\(hyat\(hymhs\(hysupported\(hyautomatic\(hyactions
.sp 1P
.LP
A.2.10\ \ \fIMHS supported content types\fR
.sp 9p
.RT
.PP
The \fBMHS supported content types\fR attribute identifies the content
types of the messages whose syntax and semantics a MS fully supports.
.PP
A value of this attribute is an object identifier.
.RT
.LP
mhs\(hysupported\(hycontent\(hytypes ATTRIBUTE
.LP
WITH ATTRIBUTE\(hySYNTAX objectIdentifierSyntax
.LP
MULTI VALUE
.LP
::= id\(hyat\(hymhs\(hysupported\(hycontent\(hytypes
.sp 1P
.LP
A.2.11\ \ \fIMHS supported optional attributes\fR
.sp 9p
.RT
.PP
The \fBMHS supported optional attributes\fR attribute identifies the
optional attributes that an MS fully supports.
.PP
A value of this attribute is an Object Identifier.
.RT
.LP
mhs\(hysupported\(hyoptional\(hyattributes ATTRIBUTE
.LP
WITH ATTRIBUTE\(hySYNTAX objectIdentifierSyntax
.LP
MULTI VALUE
.LP
::= id\(hyat\(hymhs\(hysupported\(hyoptional\(hyattributes
.sp 1P
.LP
A.3
\fIAttribute syntaxes\fR
.sp 9p
.RT
.PP
The attribute syntaxes specific to message handling are those
specified below.
.RT
.sp 1P
.LP
A.3.1
\fIMHS DL submit permission\fR
.sp 9p
.RT
.PP
The \fBMHS DL submit permission\fR attribute syntax characterizes an
attribute each of whose values is a submit permission.
.RT
.LP
mhs\(hydl\(hysubmit\(hypermission\(hysyntax ATTRIBUTE\(hySYNTAX
.LP
SYNTAX DLSubmitPermission
.LP
MATCHES FOR EQUALITY
.LP
::= id\(hyas\(hymhs\(hydl\(hysubmit\(hypermission
.LP
DLSubmitPermission ::= CHOICE\|{
.LP
individual
[0] ORName,
.LP
member\(hyof\(hydl
[1] ORName,
.LP
pattern\(hymatch
[2] ORNamePattern,
.LP
member\(hyof\(hygroup
[3] Name\|}
.PP
A presented DL submit permission value shall be of type
\fIIndividual\fR .
.PP
A DL submit permission, depending upon its type, grants submit access to
the following zero or more users and DLs:
.RT
.LP
a)
\fIIndividual\fR \|: The user or (unexpanded) DL any of whose O/R names
is equal to the specified O/R name.
.LP
b)
\fIMember\(hyof\(hydl\fR \|: Each member of the DL, any of whose O/R
names is equal to the specified O/R name, or of each nested DL,
recursively.
.LP
c)
\fIPattern\(hymatch\fR \|: Each user or (unexpanded) DL any of whose
O/R names matches the specified O/R name pattern.
.LP
ORNamePattern ::= ORName
.bp
.LP
d)
\fIMember\(hyof\(hygroup\fR \|: Each member of the group\(hyof\(hynames whose
name is specified, or of each nested group\(hyof\(hynames,
recursively.
.PP
A presented value is equal to a target value of this type if the two are
identical, attribute by attribute. Additionally, equality may be
declared under other conditions which are a local matter.
.sp 1P
.LP
A.3.2
\fIMHS O/R address\fR
.sp 9p
.RT
.PP
The \fBMHS O/R address\fR attribute syntax characterizes an attribute
each of whose values is an O/R address.
.RT
.LP
mhs\(hyor\(hyaddress\(hysyntax ATTRIBUTE\(hySYNTAX
.LP
SYNTAX ORAddress
.LP
MATCHES FOR EQUALITY
.LP
::= id\(hyas\(hymhs\(hyor\(hyaddress
.PP
A presented O/R address value is equal to a target O/R address value under
the conditions specified in\ \(sc\ 18.4.
.sp 1P
.LP
A.3.3
\fIMHS O/R name\fR
.sp 9p
.RT
.PP
The \fBMHS O/R name\fR attribute syntax characterizes an attribute each
of whose values is an O/R name.
.RT
.LP
mhs\(hyor\(hyname\(hysyntax ATTRIBUTE\(hySYNTAX
.LP
SYNTAX ORName
.LP
MATCHES FOR EQUALITY
.LP
::= id\(hyas\(hymhs\(hyor\(hyname
.PP
A presented O/R name value is equal to a target O/R name value if
the two are identical, attribute by attribute. Additionally, equality may be
declared under other conditions which are a local matter.
\v'1P'
.ce 1000
ANNEX\ B
.ce 0
.ce 1000
(to Recommendation X.402)
.sp 9p
.RT
.ce 0
.ce 1000
\fBReference definition of object identifiers\fR
.sp 1P
.RT
.ce 0
.PP
This Annex is an integral part of this Recommendation.
.sp 1P
.RT
.PP
This Annex defines for reference purposes various object
identifiers cited in the ASN.1 module of Annex\ C. It uses ASN.1.
.PP
All object identifiers this Recommendation assigns are assigned in
this Annex. Annex\ B is definitive for all but those for ASN.1 modules and
MHS itself. The definitive assignments for the former occur in the modules
themselves; other references to them appear in IMPORT clauses. The latter is
fixed.
.RT
.sp 1P
.LP
MHSObjectIdentifiers {\|joint\(hyiso\(hyccitt
.sp 9p
.RT
.LP
mhs\(hymotis(6) arch(5) modules(0) object\(hyidentifiers(0)\|}
.LP
DEFINITIONS IMPLICIT TAGS ::=
.LP
BEGIN
\(hy\(hy\ \fIPrologue\fR
.LP
\(hy\(hy\ \fIExports everything.\fR
.LP
IMPORTS\ \(hy\(hy\ \fInothing\fR \ \(hy\(hy\ ;
.LP
ID ::= OBJECT IDENTIFIER
.sp 1P
.LP
\(hy\(hy\ \fIAspects MHS\fR
.sp 9p
.RT
.LP
id\(hymhsac
ID ::= {\|joint\(hyiso\(hyccitt mhs\(hymotis(6)\ mhsac(0)\|}
.LP
\(hy\(hy\ \fIMHS Application Contexts\fR
.LP
\(hy\(hy\ \fISee Recommendation X.419\fR .
.bp
.LP
id\(hyipms
ID ::= {\|joint\(hyiso\(hyccitt mhs\(hymotis(6) ipms(1)\|}
.LP
\(hy\(hy\ \fIInterpersonal Messaging\fR
.LP
\(hy\(hy\ \fISee Recommendation X.420\fR .
.LP
id\(hyasdc
ID ::= {\|joint\(hyiso\(hyccitt mhs\(hymotis(6) asdc(2)\|}
.LP
\(hy\(hy\ \fIAbstract Service Definition Conventions\fR
.LP
\(hy\(hy\ \fISee Recommendation X.407\fR .
.LP
id\(hymts
ID ::= {\|joint\(hyiso\(hyccitt mhs\(hymotis(6) mts(3)\|}
.LP
\(hy\(hy\ \fIMessage Transfer System\fR
.LP
\(hy\(hy\ \fISee Recommendation X.411\fR .
.LP
id\(hyms
ID ::= {\|joint\(hyiso\(hyccitt mhs\(hymotis(6) ms(4)\|}
.LP
\(hy\(hy\ \fIMessage Store\fR
.LP
\(hy\(hy\ \fISee Recommendation X.413\fR .
.LP
id\(hyarch
ID ::= {\|joint\(hyiso\(hyccitt mhs\(hymotis(6) arch(5)\|}
.LP
\(hy\(hy\ \fIOverall Architecture\fR
.LP
\(hy\(hy\ \fISee this Recommendation\fR .
.LP
id\(hygroup
ID ::= {\|joint\(hyiso\(hyccitt mhs\(hymotis(6) group(6)\|}
.LP
\(hy\(hy\ \fIReserved\fR .
.sp 1P
.LP
\(hy\(hy\ \fICategories\fR
.sp 9p
.RT
.LP
id\(hymod
ID ::= {\|id\(hyarch\ 0\|}\ \(hy\(hy\ \fImodules, not definitive\fR
.LP
id\(hyoc
ID ::= {\|id\(hyarch\ 1\|}\ \(hy\(hy\ \fIobject classes\fR
.LP
id\(hyat
ID ::= {\|id\(hyarch\ 2\|}\ \(hy\(hy\ \fIattribute types\fR
.LP
id\(hyas
ID ::= {\|id\(hyarch\ 3\|}\ \(hy\(hy\ \fIattribute syntaxes\fR
.sp 1P
.LP
\(hy\(hy\ \fIModules\fR
.sp 9p
.RT
.LP
id\(hyobject\(hyidentifiers
ID ::= {\|id\(hymod\ 0\|}\ \(hy\(hy\ \fInot definitive\fR
.LP
id\(hydirectory\(hyobjects\(hyand\(hyattributes;
ID ::= {\|id\(hymod\ 1\|}
.LP
\ \(hy\(hy\ \fInot definitive\fR
.sp 1P
.LP
\(hy\(hy\ \fIObject classes\fR
.sp 9p
.RT
.LP
id\(hyoc\(hymhs\(hydistribution\(hylist
ID ::= {\|id\(hyoc\ 0\|}
.LP
id\(hyoc\(hymhs\(hymessage\(hystore
ID ::= {\|id\(hyoc\ 1\|}
.LP
id\(hyoc\(hymhs\(hymessage\(hytransfer\(hyagent
ID ::= {\|id\(hyoc\ 2\|}
.LP
id\(hyoc\(hymhs\(hyuser
ID ::= {\|id\(hyoc\ 3\|}
.LP
id\(hyoc\(hymhs\(hyuser\(hyagent
ID ::= {\|id\(hyoc\ 4\|}
.sp 1P
.LP
\(hy\(hy\ \fIAttributes\fR
.sp 9p
.RT
.LP
id\(hyat\(hymhs\(hydeliverable\(hycontent\(hylegth
ID ::= {\|id\(hyat\ 0\|}
.LP
id\(hyat\(hymhs\(hydeliverable\(hycontent\(hytypes
ID ::= {\|id\(hyat\ 1\|}
.LP
id\(hyat\(hymhs\(hydeliverable\(hyeits
ID ::= {\|id\(hyat\ 2\|}
.LP
id\(hyat\(hymhs\(hydl\(hymembers
ID ::= {\|id\(hyat\ 3\|}
.LP
id\(hyat\(hymhs\(hydl\(hysubmit\(hypermissions
ID ::= {\|id\(hyat\ 4\|}
.LP
id\(hyat\(hymhs\(hymessage\(hystore
ID ::= {\|id\(hyat\ 5\|}
.LP
id\(hyat\(hymhs\(hyor\(hyaddresses
ID ::= {\|id\(hyat\ 6\|}
.LP
id\(hyat\(hymhs\(hypreferred\(hydelivery\(hymethods
ID ::= {\|id\(hyat\ 7\|}
.LP
id\(hyat\(hymhs\(hysupported\(hyautomatic\(hyactions
ID ::= {\|id\(hyat\ 8\|}
.LP
id\(hyat\(hymhs\(hysupported\(hycontent\(hytypes
ID ::= {\|id\(hyat\ 9\|}
.LP
id\(hyat\(hymhs\(hysupported\(hyoptional\(hyattributes
ID ::= {\|id\(hyat\ 10\|}
.sp 1P
.LP
\(hy\(hy\ \fIAttribute syntaxes\fR
.sp 9p
.RT
.LP
id\(hyas\(hymhs\(hydl\(hysubmit\(hypermission
ID\ ::= {\|id\(hyas\ 0\|}
.LP
id\(hyas\(hymhs\(hyor\(hyaddress
ID\ ::=\|{\|id\(hyas\ 1\|}
.LP
id\(hyas\(hymhs\(hyor\(hyname
ID\ ::=\|{\|id\(hyas\ 2\|}
.LP
END\ \(hy\(hy\ \fIof MHSObjectIdentifiers\fR .bp
.ce 1000
ANNEX\ C
.ce 0
.ce 1000
(to Recommendation X.402)
.sp 9p
.RT
.ce 0
.ce 1000
\fBReference definition of directory object
classes and attributes\fR
.sp 1P
.RT
.ce 0
.PP
This Annex is an integral part of this Recommendation.
.sp 1P
.RT
.PP
This Annex, a supplement to Annex A, defines for
reference purposes the object classes, attributes, and attribute syntaxes
specific to Message Handling. It uses the OBJECT\(hyCLASS, ATTRIBUTE, and
ATTRIBUTE\(hySYNTAX macros of Recommendation\ X.501.
.sp 1P
.LP
MHSDirectoryObjectsAndAttributes\|{\|joint\(hyiso\(hyccitt
.sp 9p
.RT
.LP
mhs\(hymotis(6) arch(5) modules(0) directory(1)\|}
.LP
DEFINITIONS IMPLICIT TAGS ::=
.LP
BEGIN
\(hy\(hy\ \fIPrologue\fR
.LP
\(hy\(hy\ \fIExports everything\fR .
.sp 1P
.LP
IMPORTS
.sp 9p
.RT
.LP
\(hy\(hy\ \fIMHS object identifiers\fR
.LP
id\(hyas\(hymhs\(hydl\(hysubmit\(hypermission, id\(hyas\(hymhs\(hyor\(hyaddress,
.LP
id\(hyas\(hymhs\(hyor\(hyname\(hy, id\(hyat\(hymhs\(hydeliverable\(hycontent\(hylength,
.LP
id\(hyat\(hymhs\(hydeliverable\(hycontent\(hytypes,
.LP
id\(hyat\(hymhs\(hydeliverable\(hyeits, id\(hyat\(hymhs\(hydl\(hymembers,
.LP
id\(hyat\(hymhs\(hydl\(hysubmit\(hypermissions, id\(hyat\(hymhs\(hymessage\(hystore,
.LP
id\(hyat\(hymhs\(hyor\(hyaddresses, id\(hyat\(hymhs\(hypreferred\(hydelivery\(hymethods,
.LP
id\(hyat\(hymhs\(hysupported\(hyautomatic\(hyactions,
.LP
id\(hyat\(hymhs\(hysupported\(hycontent\(hytypes,
.LP
id\(hyat\(hymhs\(hysupported\(hyoptional\(hyattributes,
.LP
id\(hyoc\(hymhs\(hydistribution\(hylist, id\(hyoc\(hymhs\(hymessage\(hystore,
.LP
id\(hyoc\(hymhs\(hymessage\(hytransfer\(hyagent,
.LP
id\(hyoc\(hymhs\(hyuser,
.LP
id\(hyoc\(hymhs\(hyuser\(hyagent
.LP
\(hy\(hy\(hy\(hy
.LP
FROM MHSObjectIdentifiers\|{\|joint\(hyiso\(hyccitt
.LP
mhs\(hymotis(6) arch(5) modules(0) object\(hyidentifiers(0)\|}
.LP
\(hy\(hy\ \fIMTS Abstract service\fR
.LP
ORAddress, ORName, RequestedDeliveryMethod
.LP
\(hy\(hy\(hy\(hy
.LP
FROM MTSAbstractService\|{\|joint\(hyiso\(hyccitt
.LP
mhs\(hymotis(6) mts(3) modules(0) MTS\(hyabstract\(hyservice(3)\|}
.LP
\(hy\(hy\ \fIInformation framework\fR
.LP
ATTRIBUTE, ATTRIBUTE\(hySYNTAX, Name, OBJECT\(hyCLASS
.LP
\(hy\(hy\(hy\(hy
.LP
FROM informationFramework\|{\|joint\(hyiso\(hyccitt
.LP
ds(5) modules(1) informationFramework(1)\|}
.LP
\(hy\(hy\ \fISelected object classes\fR
.LP
applicationEntity
.LP
top
.LP
\(hy\(hy\(hy\(hy
.LP
FROM SelectedObjectClasses\|{\|joint\(hyiso\(hyccitt
.LP
ds(5) modules(1) selectedObjectClasses(6)\|}
.LP
\(hy\(hy\ \fISelected attribute types\fR
.LP
commonName, description, distinguishedNameSyntax,
.LP
integerSyntax, objectidentifierSyntax, organization,
.LP
organizationalUnitName, owner, seeAlso
.LP
\(hy\(hy\(hy\(hy
.LP
FROM SelectedAttributeTypes\|{\|joint\(hyiso\(hyccitt
.LP
ds(5) modules(1) selectedAttributeTypes(5)\|}
.bp
.sp 1P
.LP
\(hy\(hy\ \fIOBJECT CLASSES\fR
.sp 9p
.RT
.LP
\(hy\(hy\ \fIMHS distribution list\fR
.LP
mhs\(hydistribution\(hylist OBJECT\(hyCLASS
.LP
SUBCLASS OF top
.LP
MUST CONTAIN {
.LP
commonName,
.LP
mhs\(hydl\(hysubmit\(hypermissions,
.LP
mhs\(hyor\(hyaddresses\|}
.LP
MAY CONTAIN\|{
.LP
description,
.LP
organization,
.LP
organizationalUnitName,
.LP
owner,
.LP
seeAlso,
.LP
mhs\(hydeliverable\(hycontent\(hytypes,
.LP
mhs\(hydeliverable\(hyeits,
.LP
mhs\(hydl\(hymembers,
.LP
mhs\(hypreferred\(hydelivery\(hymethods\|}
.LP
:: id\(hyoc\(hymhs\(hydistribution\(hylist
.LP
\(hy\(hy\ \fIMHS message store\fR
.LP
mhs\(hymessage\(hystore OBJECT\(hyCLASS
.LP
SUBCLASS OF applicationEntity
.LP
MAY CONTAIN\|{
.LP
description,
.LP
owner,
.LP
mhs\(hysupported\(hyoptional\(hyattributes,
.LP
mhs\(hysupported\(hyautomatic\(hyactions,
.LP
mhs\(hysupported\(hycontent\(hytypes\|}
.LP
::= id\(hyoc\(hymhs\(hymessage\(hystore
.LP
\(hy\(hy\ \fIMHS message transfer agent\fR
.LP
mhs\(hymessage\(hytransfer\(hyagent OBJECT\(hyCLASS
.LP
SUBCLASS OF applicationEntity
.LP
MAY CONTAIN\|{
.LP
description,
.LP
owner,
.LP
mhs\(hydeliverable\(hycontent\(hylength\|}
.LP
::= id\(hyoc\(hymhs\(hymessage\(hytransfer\(hyagent
.LP
\(hy\(hy\ \fIMHS user\fR
.LP
mhs\(hyuser OBJECT\(hyCLASS
.LP
SUBCLASS OF top
.LP
MUST CONTAIN\|{
.LP
mhs\(hyor\(hyaddresses\|}
.LP
MAY CONTAIN\|{
.LP
mhs\(hydeliverable\(hycontent\(hylength,
.LP
mhs\(hydeliverable\(hycontent\(hytypes,
.LP
mhs\(hydeliverable\(hyeits,
.LP
mhs\(hymessage\(hystore,
.LP
mhs\(hypreferred\(hydelivery\(hymethods\|}
.LP
::= id\(hyoc\(hymhs\(hyuser
.LP
\(hy\(hy\ \fIMHS user agent\fR
.LP
mhs\(hyuser\(hyagent OBJECT\(hyCLASS
.LP
SUBCLASS OF applicationEntity
.LP
MAY CONTAIN\|{
.LP
owner,
.LP
mhs\(hydeliverable\(hycontent\(hylength,
.LP
mhs\(hydeliverable\(hycontent\(hytypes,
.LP
mhs\(hydeliverable\(hyeits,
.LP
mhs\(hyor\(hyaddresses\|}
.LP
::= id\(hyoc\(hymhs\(hyuser\(hyagent
.bp
.sp 1P
.LP
\(hy\(hy\ \fIATTRIBUTES\fR
.sp 9p
.RT
.LP
\(hy\(hy\ \fIMHS deliverable content length\fR
.LP
mhs\(hydeliverable\(hycontent\(hylength ATTRIBUTE
.LP
WITH ATTRIBUTE\(hySYNTAX integerSyntax
.LP
SINGLE VALUE
.LP
::= id\(hyat\(hymhs\(hydeliverable\(hycontent\(hylength
.LP
\(hy\(hy\ \fIMHS deliverable content types\fR
.LP
mhs\(hydeliverable\(hycontent\(hytypes ATTRIBUTE
.LP
WITH ATTRIBUTE\(hySYNTAX objectIdentifierSyntax
.LP
MULTI VALUE
.LP
::= id\(hyat\(hymhs\(hydeliverable\(hycontent\(hytypes
.LP
\(hy\(hy\ \fIMHS deliverable EITs\fR
.LP
mhs\(hydeliverable\(hyeits ATTRIBUTE
.LP
WITH ATTRIBUTE\(hySYNTAX objectIdentifierSyntax
.LP
MULTI VALUE
.LP
::= id\(hyat\(hymhs\(hydeliverable\(hyeits
.LP
\(hy\(hy\ \fIMHS DL members\fR
.LP
mhs\(hydl\(hymembers ATTRIBUTE
.LP
WITH ATTRIBUTE\(hySYNTAX mhs\(hyor\(hyname\(hysyntax
.LP
MULTI VALUE
.LP
::= id\(hyat\(hymhs\(hydl\(hymembers
.LP
\(hy\(hy\ \fIMHS DL submit permissions\fR
.LP
mhs\(hydl\(hysubmit\(hypermissions ATTRIBUTE
.LP
WITH ATTRIBUTE\(hySYNTAX mhs\(hydl\(hysubmit\(hypermission\(hysyntax
.LP
MULTI VALUE
.LP
::= id\(hyat\(hymhs\(hydl\(hysubmit\(hypermissions
.LP
\(hy\(hy\ \fIMHS O/R adresses\fR
.LP
mhs\(hyor\(hyaddresses ATTRIBUTE
.LP
WITH ATTRIBUTE\(hySYNTAX mhs\(hyor\(hyaddress\(hysyntax
.LP
MULTI VALUE
.LP
::= id\(hyat\(hymhs\(hyor\(hyaddresses
.LP
\(hy\(hy\ \fIMHS message store\fR
.LP
mhs\(hymessage\(hystore ATTRIBUTE
.LP
WITH ATTRIBUTE\(hySYNTAX distinguishedNameSyntax
.LP
SINGLE VALUE
.LP
::= id\(hyat\(hymhs\(hymessage\(hystore
.LP
\(hy\(hy\ \fIMHS preferred delivery methods\fR
.LP
mhs\(hypreferred\(hydelivery\(hymethods ATTRIBUTE
.LP
WITH ATTRIBUTE\(hySYNTAX RequestedDeliveryMethod
.LP
MATCHES FOR EQUALITY
.LP
SINGLE VALUE
.LP
::= id\(hyat\(hymhs\(hypreferred\(hydelivery\(hymethods
.LP
\(hy\(hy\ \fIMHS supported automatic actions\fR
.LP
mhs\(hysupported\(hyautomatic\(hyactions ATTRIBUTE
.LP
WITH ATTRIBUTE\(hySYNTAX objectIdentifierSyntax
.LP
MULTI VALUE
.LP
::= id\(hyat\(hymhs\(hysupported\(hyautomatic\(hyactions
.LP
\(hy\(hy\ \fIMHS supported content types\fR
.LP
mhs\(hysuppported\(hycontent\(hytypes ATTRIBUTE
.LP
WITH ATTRIBUTE\(hySYNTAX objectIdentifierSyntax
.LP
MULTI VALUE
.LP
::= id\(hyat\(hymhs\(hysupported\(hycontent\(hytypes
.LP
\(hy\(hy\ \fIMHS supported optional attributes\fR
.LP
mhs\(hysupported\(hyoptional\(hyattributes ATTRIBUTE
.LP
WITH ATTRIBUTE\(hySYNTAX objectIdentifierSyntax
.LP
MULTI VALUE
.LP
::= id\(hyat\(hymhs\(hysupported\(hyoptional\(hyattributes
.bp
.sp 1P
.LP
\(hy\(hy\ \fIATTRIBUTE SYNTAXES\fR
.sp 9p
.RT
.LP
\(hy\(hy\ \fIMHS DL submit permission\fR
.LP
mhs\(hydl\(hysubmit\(hypermission\(hysyntax ATTRIBUTE\(hySYNTAX
.LP
SYNTAX DLSubmitPermission
.LP
MATCHES FOR EQUALITY
.LP
::= id\(hyas\(hymhs\(hydl\(hysubmit\(hypermission
DLSubmitPermission ::= CHOICE\|{
.LP
individual
[0]\ ORName,
.LP
member\(hyof\(hydl
[1]\ ORName,
.LP
pattern\(hymatch
[2]\ ORNamePattern,
.LP
member\(hyof\(hygroup
[3]\ Name\|}
ORNamePattern ::= ORName
.LP
\(hy\(hy\ \fIMHS O/R addresses\fR
.LP
mhs\(hyor\(hyaddress\(hysyntax ATTRIBUTE\(hySYNTAX
.LP
SYNTAX ORAddress
.LP
MATCHES FOR EQUALITY
.LP
::= id\(hyas\(hymhs\(hyor\(hyaddress
.LP
\(hy\(hy\ \fIMHS O/R name\fR
.LP
mhs\(hyor\(hyname\(hysyntax ATTRIBUTE\(hySYNTAX
.LP
SYNTAX ORName
.LP
MATCHES FOR EQUALITY
.LP
::= id\(hyas\(hymhs\(hyor\(hyname
.LP
END\ \(hy\(hy\ \fIof MHSdirectory\fR \v'1P'
.ce 1000
ANNEX\ D
.ce 0
.ce 1000
\fBSecurity threats\fR
.sp 1P
.RT
.ce 0
.PP
This Annex is not a part of this Recommendation.
.sp 1P
.RT
.PP
An overview of MHS security threats is provided in \(sc\ 15.1 of
Recommendation\ X.400. This considers threats as they appear in an MHS
access threats, inter\(hymessage threats, and message store threats. These
threats can appear in various forms as follows:
.LP
a)
masquerade;
.LP
b)
message sequencing;
.LP
c)
modification of information;
.LP
d)
denial of service;
.LP
e)
leakage of information;
.LP
f
)
repudiation;
.LP
g)
other MHS threats.
.PP
In addition, they may occur by accident or by malicious intent and may
be active or passive. Attacks on the MHS will address potential
weaknesses and may comprise of a number of threats. This Annex deals with
individual threats and although consideration is given to a number of broad
classes of threat, it is not a complete list.
.PP
Table D\(hy1/X.402 indicates how these threats can be met using the MHS
security services. The list of threats given here is indicative rather
than
definitive.
.bp
.RT
.ce
\fBH.T. [T13.402]\fR
.ce
TABLE\ D\(hy1/X.402
.ce
\fBUse of MHS security services\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(96p) | cw(96p) .
Threat Services
_
.T&
lw(96p) | lw(96p) .
\fIMasquerade\fR
.T&
lw(96p) | lw(96p) .
T{
Impersonation and misuse of the MTS
T} T{
Message origin authentication
Probe origin authentication
Secure access management
T}
.T&
lw(96p) | lw(96p) .
Falsely acknowledge receipt Proof of delivery
.T&
lw(96p) | lw(96p) .
T{
Falsely claim to originate a message
T} Message origin authentication
.T&
lw(96p) | lw(96p) .
T{
Impersonation of an MTA to an MTS\(hyuser
T} T{
Proof of submission
Report origin authentication
Secure access management
T}
.T&
lw(96p) | lw(96p) .
T{
Impersonation of an MTA to another MTA
T} T{
Report origin authentication
Secure access management
T}
_
.T&
lw(96p) | lw(96p) .
\fIMessage sequencing\fR
.T&
lw(96p) | lw(96p) .
Replay of messages Message sequence integrity
.T&
lw(96p) | lw(96p) .
Re\(hyordering of messages Message sequence integrity
.T&
lw(96p) | lw(96p) .
Pre\(hyplay of messages
.T&
lw(96p) | lw(96p) .
Delay of messages
_
.T&
lw(96p) | lw(96p) .
T{
\fIModification of information\fR
T}
.T&
lw(96p) | lw(96p) .
Modification of messages T{
Connection integrity
Content integrity
T}
.T&
lw(96p) | lw(96p) .
Destruction of messages Message sequence integrity
.T&
lw(96p) | lw(96p) .
T{
Corruption of routing and other management information
T}
_
.T&
lw(96p) | lw(96p) .
\fIDenial of service\fR
.T&
lw(96p) | lw(96p) .
Denial of communications
.T&
lw(96p) | lw(96p) .
MTA flooding
.T&
lw(96p) | lw(96p) .
MTS flooding
_
.T&
lw(96p) | lw(96p) .
\fIRepudiation\fR
.T&
lw(96p) | lw(96p) .
Denial of origin Non\(hyrepudiation of origin
.T&
lw(96p) | lw(96p) .
Denial of submission T{
Non\(hyrepudiation of submission
T}
.T&
lw(96p) | lw(96p) .
Denial of delivery T{
Non\(hyrepudiation of delivery
T}
_
.T&
lw(96p) | lw(96p) .
T{
\fILeakage of information\fR
T}
.T&
lw(96p) | lw(96p) .
Loss of confidentiality T{
Connection confidentiality
Content confidentiality
T}
.T&
lw(96p) | lw(96p) .
Loss of anonymity Message flow confidentiality
.T&
lw(96p) | lw(96p) .
Misappropriation of messages Secure access management
.T&
lw(96p) | lw(96p) .
Traffic analysis Message flow confidentiality
_
.T&
lw(96p) | lw(96p) .
\fIOther threats\fR
.T&
lw(96p) | lw(96p) .
T{
Originator not cleared for message security label
T} T{
Secure access management
Message security labelling
T}
.T&
lw(96p) | lw(96p) .
T{
MTA/MTS\(hyuser not cleared for security context
T} Secure access management
.T&
lw(96p) | lw(96p) .
Misrouting T{
Secure access management
Message security labelling
T}
.T&
lw(96p) | lw(96p) .
Differing labelling policies
_
.TE
.nr PS 9
.RT
.ad r
\fBTable D\(hy1/X.402 [T13.402], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 1P
.LP
D.1
\fIMasquerade\fR
.sp 9p
.RT
.PP
Masquerade occurs when an entity successfully pretends to be a
different entity and can take place in a number of ways. An unauthorized
MTS\(hyuser may impersonate another to gain unauthorized access to MTS
facilities or to act to the detriment of the valid user, e.g.,\ to discard
his messages. An MTS\(hyuser may impersonate another user and so falsely
acknowledge receipt of a message by the \*Qvalid\*U recipient. A message
may be put into the MTS by a user falsely claiming the identity of another
user. An MTS\(hyuser, MS, or MTA may
masquerade as another MTS user, MS, or MTA.
.PP
Masquerade threats include the following:
.RT
.LP
a)
impersonation and misuse of the MTS;
.LP
b)
falsely acknowledge receipt;
.LP
c)
falsely claim to originate a message;
.LP
d)
impersonation of an MTA to an MTS\(hyuser;
.LP
e)
impersonation of an MTA to another MTA.
.PP
A masquerade usually consists of other forms of attack and in a
secure system may involve authentication sequences from valid users, e.g.,\
in replay or modification of messages.
.sp 1P
.LP
D.2
\fIMessage sequencing\fR
.sp 9p
.RT
.PP
Message sequencing threats occur when part or all of a message is repeated,
time\(hyshifted, or reordered. This can be used to exploit the
authentication information in a valid message and resequence or time\(hyshift
valid messages. Although it is impossible to prevent replay with the MHS
security services, it can be detected and the effects of the threat
eliminated.
.PP
Message sequencing threats include the following:
.RT
.LP
a)
replay of messages;
.LP
b)
reordering of messages;
.LP
c)
pre\(hyplay of messages;
.LP
d)
delay of messages.
.sp 1P
.LP
D.3
\fIModification of information\fR
.sp 9p
.RT
.PP
Information for an intended recipient, routing information, and
other management data may be lost or modified without detection. This could
occur to any aspect of the message, e.g.,\ its labelling, content, attributes,
recipient, or originator. Corruption of routing or other management
information, stored in MTAs or used by them, may cause the MTS to lose
messages or otherwise operate incorrectly.
.PP
Modification of information threats include the following:
.RT
.LP
a)
modification of messages;
.LP
b)
destruction of messages;
.LP
c)
corruption of routing and other management
information.
.sp 1P
.LP
D.4
\fIDenial of service\fR
.sp 9p
.RT
.PP
Denial of service occurs when an entity fails to perform its
function or prevents other entities from performing their functions. This
may be a denial of access, a denial of communications (leading to other
problems
like overload), a deliberate suppression of messages to a particular recipient,
or a fabrication of extra traffic. The MTS can be denied if an MTA has
been
caused to fail or operate incorrectly. In addition, an MTS\(hyuser may
cause the MTS to deny a service to other users by flooding the service
with messages
which might overload the switching capability of an MTA or fill up all
available message storage space.
.PP
Denial of service threats include the following:
.RT
.LP
a)
denial of communications;
.LP
b)
MTA failure;
.LP
c)
MTS flooding.
.bp
.sp 1P
.LP
D.5
\fIRepudiation\fR
.sp 9p
.RT
.PP
Repudiation can occur when an MTS\(hyuser or the MTS may later deny
submitting, receiving, or originating a message.
.PP
Repudiation threats include the following:
.RT
.LP
a)
denial of origin;
.LP
b)
denial of submission;
.LP
c)
denial of delivery.
.sp 1P
.LP
D.6
\fILeakage of information\fR
.sp 9p
.RT
.PP
Information may be acquired by an unauthorized party by monitoring transmissions,
by unauthorized access to information stored in any MHS entity, or by masquerade.
In some cases, the presence of an MTS\(hyuser on the system may be sensitive
and its anonymity may have to be preserved. An MTS\(hyuser other than the
intended recipient may obtain a message. This might result from
impersonation and misuse of the MTS or through causing an MTA to operate
incorrectly. Further details on the information flowing in an MTS may be
obtained from observing the traffic.
.PP
Leakage of information threats include the following:
.RT
.LP
a)
loss of confidentiality;
.LP
b)
loss of anonymity;
.LP
c)
misappropriation of messages;
.LP
d)
traffic analysis.
.sp 1P
.LP
D.7
\fIOther threats\fR
.sp 9p
.RT
.PP
In a multi\(hy or single\(hylevel secure system, a number of threats may
exist that relate to security labelling, e.g.,\ routing through a node that
cannot be trusted with information of particular value, or where systems use
different labelling policies. Threats may exist to the enforcement of a
security policy based on logical separation using security labels. An MTS\(hyuser
may originate a message and assign it a label for which it is not cleared.
An MTS\(hyuser or MTA may set up or accept an association with a security
context for which it does not have clearance.
.PP
Other threats include the following:
.RT
.LP
a)
originator not cleared for message label (inappropriate
submit);
.LP
b)
MTA/MTS\(hyuser not cleared for context;
.LP
c)
misrouting;
.LP
d)
differing labelling policies.
\v'1P'
.ce 1000
ANNEX\ E
.ce 0
.ce 1000
(to Recommendation X.402)
.sp 9p
.RT
.ce 0
.ce 1000
\fBProvision of security services\fR \fBin Recommendation X.411\fR
.sp 1P
.RT
.ce 0
.PP
This Annex is an integral part of this Recommendation.
.sp 1P
.RT
.PP
Table E\(hy1/X.402 indicates which service elements from
Recommendation X.411 may be used to support the security services described
in \(sc\ 10.2.
.LP
.rs
.sp 5P
.ad r
Blanc
.ad b
.RT
.LP
.bp
.ce
\fBH.T. [T14.402]\fR
.ce
TABLE\ E\(hy1/X.402
.ce
\fBMHS security service provision\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(102p) | cw(102p) .
Service MIS Arguments/services
_
.T&
lw(102p) | lw(102p) .
T{
\fIOrigin authentication security services\fR
T}
.T&
lw(102p) | lw(102p) .
Message origin authentication T{
Message origin authentication check
Message token
T}
.T&
lw(102p) | lw(102p) .
Probe origin authentication T{
Probe origin authentication check
T}
.T&
lw(102p) | lw(102p) .
Report origin authentication T{
Report origin authentication check
T}
.T&
lw(102p) | lw(102p) .
Proof of submission T{
Proof of submission request
Proof of submission
T}
.T&
lw(102p) | lw(102p) .
Proof of delivery T{
Proof of delivery request
Proof of delivery
T}
_
.T&
lw(102p) | lw(102p) .
T{
\fISecure access management security services\fR
T}
.T&
lw(102p) | lw(102p) .
Peer entity authentication T{
Initiator credentials
Responder credentials
T}
.T&
lw(102p) | lw(102p) .
Security context Security context
_
.T&
lw(102p) | lw(102p) .
T{
\fIData confidentiality security services\fR
T}
.T&
lw(102p) | lw(102p) .
Connection confidentiality Not supported
.T&
lw(102p) | lw(102p) .
Content confidentiality T{
Content confidentiality algorithm identifier
Message token
T}
.T&
lw(102p) | lw(102p) .
Message flow confidentiality Content type
_
.T&
lw(102p) | lw(102p) .
T{
\fIData integrity security services\fR
T}
.T&
lw(102p) | lw(102p) .
Connection integrity Not supported
.T&
lw(102p) | lw(102p) .
Content integrity T{
Content integrity check
Message token
Message origin authentication check
T}
.T&
lw(102p) | lw(102p) .
Message sequence integrity T{
Message sequence number
Message token
T}
_
.T&
lw(102p) | lw(102p) .
T{
\fINon\(hyrepudiation security services\fR
T}
.T&
lw(102p) | lw(102p) .
Non\(hyrepudiation of origin T{
Content integrity check
Message token
Message origin authentication check
T}
.T&
lw(102p) | lw(102p) .
T{
Non\(hyrepudiation of submission
T} T{
Proof of submission request
Proof of submission
T}
.T&
lw(102p) | lw(102p) .
T{
Non\(hyrepudiation of delivery
T} T{
Proof of delivery request
Proof of delivery
T}
_
.T&
lw(102p) | lw(102p) .
Message security labelling T{
Message security label
Message token
Message origin authentication check
T}
_
.T&
lw(102p) | lw(102p) .
T{
\fISecurity management security services\fR
T}
.T&
lw(102p) | lw(102p) .
Change credentials Change credentials
.T&
lw(102p) | lw(102p) .
Register Register
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau E\(hy1/X.402, [T14.402] p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.ce 1000
ANNEX\ F
.ce 0
.ce 1000
\fBDifferences between CCITT Recommendation and ISO Standard\fR
.sp 1P
.RT
.ce 0
.PP
This Annex is not a part of this Recommendation.
.sp 1P
.RT
.PP
This Annex lists all but the purely stylistic differences between this
Recommendation and the corresponding ISO International Standard.
.PP
The following are the differences that exist:
.RT
.LP
a)
The ISO International Standard corresponding to this
Recommendation depicts direct connection of two PRMDs in the
same country, direct connection of two PRMDs in different
countries, and a single PRMD connected to two ADMDs, while this
Recommendation does not. (See Figure\ 11/X.402.)
.LP
b)
The ISO International Standard corresponding to this
Recommendation does not require that ADMDs and PRMDs be
hierarchically related for purposes of addressing and routing,
while this Recommendation does. (See \(sc\(sc\ 14.1.1., 14.1.2, 15
and\ 19.)
.LP
c)
Where an O/R address attribute admits both printable and
teletex strings, the ISO International Standard corresponding to
this Recommendation does not require that the printable string
be supplies as a minimum whenever attributes are conveyed
internationally, while this Recommendation does. (See
\(sc\ 18.2.)
\v'1P'
.ce 1000
ANNEX\ G
.ce 0
.ce 1000
\fBIndex\fR
.sp 1P
.RT
.ce 0
.PP
This Annex is not a part of this Recommendation.
.sp 1P
.RT
.PP
This Annex indexes this Recommendation. It gives the number(s) of the section(s)
on which each item in each of several categories is defined. Its coverage
of each category is exhaustive.
.PP
This Annex indexes items (if any) in the following
categories:
.RT
.LP
a)
abbreviations;
.LP
b)
terms;
.LP
c)
information items;
.LP
d)
ASN.1 modules;
.LP
e)
ASN.1 macros;
.LP
f
)
ASN.1 types;
.LP
g)
ASN.1 values;
.LP
h)
\fIbilateral agreements\fR ;
.LP
i)
items \fBfor further study\fR ;
.LP
j
)
items \fBto be supplied (fs)\fR .
.bp
.sp 1P
.LP
G.1
\fIAbbreviations\fR
.sp 9p
.RT
.LP
.sp 1
A/SYS\
13.1.1
.LP
AC\
3.1
.LP
ACs\
27
.LP
ACSE\
3.1, 26.4.3
.LP
ADMD\
14.1.1
.LP
AE\
3.1
.LP
APDU\
3.1
.LP
AS/SYS\
13.1.3
.LP
ASE\
3.1
.LP
ASEs\
26
.LP
ASN.1\
3.1
.LP
AST/SYS\
13.1.7
.LP
AT/SYS\
13.1.5
.LP
AU\
7.2.4
.LP
C\
5.2
.LP
COMPUSEC\
10
.LP
D\
5.2
.LP
DL\
7.1.3
.LP
DSA\
3.2
.LP
EIT\
8.1
.LP
M\
5.2
.LP
MASE\
26.3.5
.LP
MD\
14.1
.LP
MDSE\
26.3.3
.LP
MHE\
7
.LP
MHS\ 7.1.1
.LP
MRSE\
26.3.4
.LP
MS\
7.2.3
.LP
MSSE\
26.3.2
.LP
MTA\
7.3.1
.LP
MTS\
7.2.1
.LP
MTSE\
26.3.1
.LP
O\
5.2
.LP
OSI\
3.1
.LP
P1\
27
.LP
P3\
27
.LP
P7\
27
.LP
PDAU\ 7.4.1
.LP
PDS\
7.4.1
.LP
PRMD\
14.1.2
.LP
RO\
3.1
.LP
ROSE\
3.1, 26.4.1
.LP
RT\
3.1
.LP
RTSE\
3.1, 26.4.2
.LP
S/SYS\
13.1.2
.LP
ST/SYS\
13.1.6
.LP
T/SYS\
13.1.4
.LP
UA\
7.2.2
.LP
UE\
3.1
.sp 1P
.LP
.sp 2
G.2
\fITerms\fR
.sp 9p
.RT
.LP
.sp 1
access and storage system\
13.1.3
.LP
access and transfer system\
13.1.5
.LP
access, storage and transfer system\
13.1.7
.LP
access system\
13.1.1
.LP
access unit\
7.2.4
.LP
actual recipient\
9.2
.LP
administration\(hydomain\(hyname\
18.3.1
.LP
administration management domain\
14.1.1
.LP
affirmation\
9.4.9
.LP
asymetric\
26.2
.LP
attribute\
18.1
.LP
attribute list\
18.1
.LP
attribute type\
18.1
.LP
attribute value\
18.1
.LP
common\(hyname\
18.3.2
.LP
conditional\
5.2
.LP
consuming ASE\
26.2
.LP
consuming UE\
26.2
.LP
content\
8.1
.LP
content type\
8.1
.LP
conversion\
9.4.6
.LP
country\(hyname\
18.3.3
.LP
defaultable\
5.2
.LP
delivery\
9.3.6
.LP
delivery agent\
9.3.6
.LP
delivery report\
8.3
.LP
described message\
8.2
.LP
direct submission\
9.3.2
.LP
direct user\
7.1.2
.LP
distribution list\
7.1.3
.LP
DL expansion\
9.4.4
.LP
domain\
14.1
.LP
domain\(hydefined attribute\
18.1
.LP
encoded information type\
18.1
.LP
envelope\
8.1
.LP
event\
9.1
.LP
expansion point\
9.4.4
.LP
explicit conversion\
9.4.6
.LP
export\
9.3.5
.LP
extension\(hyphysical\(hydelivery\(hyaddress\(hy
components\ \ 18.3.5
.LP
extension\(hypostal\(hyO/R\(hyaddress\(hycomponents\
18.3.4
.LP
external routing\
9.4.10
.LP
external transfer\
9.3.4
.LP
formatted\
18.5.3
.LP
global MHS\
15
.LP
grade\
7.5.2
.LP
immediate recipient\
9.1
.LP
implicit conversion\
9.4.6
.LP
import\
9.3.3
.LP
indirect submission\
9.3.2
.LP
indirect user\
7.1.2
.LP
intended recipient\
9.2
.LP
internal routing\
9.4.10
.LP
internal transfer\
9.3.4
.LP
joining\
9.4.2
.LP
local\(hypostal\(hyattributes\
18.3.6
.LP
management domain\
14.1
.LP
mandatory\
5.2
.LP
members\
7.1.3
.LP
member recipient\
9.2
.LP
message\
8.1
.LP
message handling\
6
.LP
message handling environment\
7
.LP
message handling system\
7.1.1
.LP
message storage\
6
.LP
message store\
7.2.3
.LP
message transfer\
6
.LP
message transfer agent\
7.3.1
.LP
message transfer system\
7.2.1
.LP
messaging system\
13.1
.LP
mnemonic O/R address\
18.5.1
.LP
name resolution\
9.4.3
.LP
nested\
7.1.3
.LP
network\(hyaddress\
18.3.7
.LP
non\(hyaffirmation\
9.4.8
.LP
non\(hydelivery\
9.4.7
.LP
non\(hydelivery report\
8.3
.LP
numeric\(hyuser\(hyidentifier\
18.3.8
.LP
numeric O/R address\
18.5.2
.LP
O/R address\
18.5
.LP
O/R name\
17.2
.LP
optional\
5.2
.LP
organization\(hyname\
18.3.9
.LP
organizational\(hyunit\(hynames\
18.3.10
.LP
origination\
9.3.1
.LP
originator\
9.2
.LP
originator\(hyspecified alternate recipient\
9.2
.LP
personal\(hyname\
18.3.12
.LP
physical\(hydelivery\(hycountry\(hyname\
18.3.13
.LP
physical\(hydelivery\(hyoffice\(hyname\
18.3.14
.LP
physical\(hydelivery\(hyoffice\(hynumber\
18.3.15
.LP
physical\(hydelivery\(hyorganization\(hyname\
18.3.16
.LP
physical\(hydelivery\(hypersonal\(hyname\
18.3.17
.LP
physical\(hydelivery\(hyservice\(hyname\
18.3.11
.LP
physical delivery\
7.4.1
.LP
physical delivery access unit\
7.4.1
.LP
physical delivery system\
7.4.1
.LP
physical message\
7.4.1
.LP
physical rendition\
7.4.1
.LP
post\(hyoffice\(hybox\(hyaddress\
18.3.18
.LP
postal\(hycode\
18.3.19
.LP
.rs
.sp 12P
.ad r
BLANC
.ad b
.RT
.LP
.bp
.LP
postal O/R address\
18.5.3
.LP
poste\(hyrestante\(hyaddress\
18.3.20
.LP
potential recipient\
9.2
.LP
private\(hydomain\(hyname\
18.3.21
.LP
private management domain\
14.1.2
.LP
probe\
8.2
.LP
receipt\
9.3.8
.LP
recipient\
9.2
.LP
recipient\(hyassigned alternate recipient\
9.2
.LP
redirection\
9.4.5
.LP
report\
8.3
.LP
retrieval\
9.3.7
.LP
routing\
9.4.10
.LP
splitting\
9.4.1
.LP
standard attribute\
18.1
.LP
step\
9.1
.LP
storage and transfer system\
13.1.6
.LP
storage system\
13.1.2
.LP
street\(hyaddress\
18.3.22
.LP
subject message\
8.3
.LP
subject probe\
8.3
.LP
submission\
9.3.2
.LP
submission agent\
19.3.2
.LP
submit permission\
7.1.3
.LP
supplying ASE\
26.2
.LP
supplying UE\
26.2
.LP
symmetric\
26.2
.LP
terminal\(hyidentifier\
18.3.23
.LP
terminal\(hytype\
18.3.24
.LP
terminal O/R address\
18.5.4
.LP
transfer\
9.3.4
.LP
transfer system\
13.1.4
.LP
transmittal\
9.1
.LP
transmittal event\
9.1
.LP
transmittal step\
9.1
.LP
type\ 18.1
.LP
unformatted\
18.5.3
.LP
unformatted\(hypostal\(hyaddress\
18.3.25
.LP
unique\(hypostal\(hyname\
18.3.26
.LP
user\
7.1.2
.LP
user agent\
7.2.2
.LP
value\
18.1
.LP
.rs
.sp 12P
.ad r
Blanc
.ad b
.RT
.LP
.bp
.LP
.bp